Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2019-17558 (Apache Solr VelocityResponseWriter Plug-In Remote Code…
Threats, Abuse & Incident Response

Is CVE-2019-17558 (Apache Solr VelocityResponseWriter Plug-In Remote Code Execution) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2019-17558 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. The Apache Solr VelocityResponseWriter plug-in contains an unspecified vulnerability which can allow for remote code execution. Any organisation running the affected product should treat remediation as urgent.

Why active exploitation changes the priority for CVE-2019-17558

CVE-2019-17558 should be treated as more than a theoretical Apache Solr issue because the question is not whether the flaw exists, but whether it is being used against real systems. Once a vulnerability reaches KEV, the practical question becomes exposure control: inventory where the VelocityResponseWriter plug-in is enabled, confirm whether the Solr instance is reachable, and assume attacker interest is already proven.

An actively exploited vulnerabilities guide is the right place to anchor this response because KEV-listed issues need fast triage, not routine backlog handling. The operational mistake is to wait for a full vulnerability-management cycle when the exploit path is already established.

What exposure to check first in Apache Solr

The first check is whether your environment actually uses the Apache Solr VelocityResponseWriter plug-in, and whether that component is exposed in a way an attacker can reach. If the vulnerable plug-in is present in a live search platform, the risk is not limited to the Solr process itself, because remote code execution can become a foothold for broader host compromise, data access, or lateral movement.

Use your vulnerability management guide process to validate asset scope, prioritize KEV items ahead of lower-confidence findings, and record whether the issue is internet-facing, internally reachable, or already isolated. That distinction affects how urgent the containment decision should be.

How to handle remediation, delay, and compromise checks

The practical response is to apply the vendor fix or mitigation as soon as possible and to treat any delay as a temporary exception that needs compensating controls. If patching cannot happen immediately, reduce exposure by restricting access to the Solr service, limiting who can reach it, and monitoring for suspicious requests or unexpected process activity.

For a fast-moving RCE, the important follow-up is to look for earlier compromise, not just to verify that the vulnerability is now closed. Review logs, process creation, outbound connections, and any signs of unexpected command execution, then rotate credentials or service tokens only if the investigation shows they may have been exposed through the compromised host or application path.

Risk and Threat Considerations

KEV inclusion means the flaw has crossed from product risk into active threat reality. For an RCE in a search service, the likely failure mode is direct code execution on the Solr host, followed by host-level persistence, data access, or pivoting into adjacent systems if the service is not tightly contained.

Failure mechanism: An attacker can send crafted input to the vulnerable VelocityResponseWriter path, gain execution on the server, and then use that execution to explore files, credentials, or reachable internal services.

Impact: The result can include full compromise of the Solr instance, disclosure of indexed or adjacent data, service disruption, and a wider breach if the host has trusted network access or reusable credentials.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack surface, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementKEV-listed RCEs require rapid identification and remediation of exposed assets.
Recommendation — Prioritize the KEV issue, verify exposure, and track remediation until the vulnerable plug-in is removed or fixed.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationAn actively exploited vulnerability calls for timely remediation and exception control.
RA-5 — Vulnerability Monitoring and ScanningExposure must be confirmed with current asset and scan data before prioritizing response.
Recommendation — Apply timely flaw remediation and document any temporary exception with compensating controls. Validate where the vulnerable Solr component exists and whether it is reachable in production.
ISO/IEC 27001:2022A.8.8 — Management of technical vulnerabilitiesActive exploitation makes technical vulnerability handling and remediation prioritization directly relevant.
Recommendation — Treat the KEV entry as a priority vulnerability and evidence the remediation decision.
MITRE ATT&CKT1190 — Exploit Public-Facing ApplicationThe issue is an internet-reachable RCE path that attackers can use against exposed services.
Recommendation — Hunt for signs of exploitation on any exposed Solr instance and inspect for follow-on activity.

Practitioner Guidance

What to verify: Confirm whether the vulnerable plug-in exists in production, whether it is externally reachable, and whether compensating controls are actually enforced rather than assumed. If the service is present but not actively needed, removal is often a stronger outcome than postponing remediation.

Decision rule: If the Solr service can be reached by untrusted users or other low-trust systems, treat this as an urgent remediation item and schedule compromise review at the same time, not after patching. If access is tightly restricted and there is evidence of no exposure, you still need a documented completion path, because KEV status means the risk is time-sensitive.

Practitioner takeaway: For KEV-listed RCEs, the right question is not whether the flaw is severe in theory, but whether the affected service is still exposed long enough for an attacker to use it.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org