CVE-2019-17558
Oracle Primavera Unifier 17.7 – 17.12
Raw vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2019-17558 is a high-severity Injection (CWE-74) vulnerability in Oracle Primavera Unifier. Its CVSS base score is 7.5 (High).
Operationally, ranked in the top 0.1% of CVEs by exploit likelihood; CISA has added it to the Known Exploited Vulnerabilities catalog; a public proof-of-concept is referenced.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Apache Solr versions 5.0.0 through 8.3.1 contain a remote code execution vulnerability in the VelocityResponseWriter component. The issue stems from the ability to supply Velocity templates either via a user-controlled configset in the velocity/ directory or through request parameters when the params.resource.loader.enabled setting is activated on a custom response writer. Because these templates are rendered without sufficient sandboxing, an attacker-supplied template can execute arbitrary code on the Solr server. The CVSS 7.5 score reflects the high impact on confidentiality, integrity, and availability when the flaw is successfully triggered.
Exploitation requires an attacker to either upload a malicious configset or obtain access to the Solr configuration API in order to define a response writer with the parameter resource loader enabled. Once a template containing executable directives is rendered, the attacker can achieve full remote code execution under the privileges of the Solr process. The attack complexity is rated high because parameter-based templates are disabled by default and configset uploads typically require authentication.
Advisories and the Solr 8.4 release notes state that the params resource loader has been removed entirely. Configset-provided Velocity templates are now rendered only when the configset is marked trusted, which occurs solely for uploads performed by authenticated users. Security practitioners are advised to upgrade to Solr 8.4 or later and to restrict configuration API access to trusted administrators.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2020-0320
Vulnerability Data
Apache Solr 5.0.0 to Apache Solr 8.3.1 are vulnerable to a Remote Code Execution through the VelocityResponseWriter. A Velocity template can be provided through Velocity templates in a configset `velocity/` directory or as a parameter. A user defined configset could…
more
contain renderable, potentially malicious, templates. Parameter provided templates are disabled by default, but can be enabled by setting `params.resource.loader.enabled` by defining a response writer with that setting set to `true`. Defining a response writer requires configuration API access. Solr 8.4 removed the params resource loader entirely, and only enables the configset-provided template rendering when the configset is `trusted` (has been uploaded by an authenticated user).
- CWE(s)
- KEV Date Added
- 03 November 2021
Related Threats
CVEs Like This One
Affected Assets
Mitigating Controls
Likely Mitigating Controls AI
Per-CVE control mapping for this CVE has not run yet; the list below is derived from the weakness types (CWEs) cited in the NVD entry.
Developer assessments and testing (including injection-focused techniques) identify improper neutralization of special elements, and the verifiable flaw remediation corrects them pre-deployment.
Identifies indicators of injection attacks (command, SQL, LDAP, etc.) via anomaly and attack monitoring.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Logging supports detection of injection attempts but does not prevent the weakness.
Monitoring activities can identify active injection attacks after they occur.
A.8.25 mandates a secure SDLC process that includes secure coding guidelines, security requirements, checkpoints, testing (scans/penetration), and developer training to reduce injection flaws, but does not itself enforce or guarantee neutralization of special elements at runtime.
Application security requirements explicitly call for controls against injection attacks in software design.
A.8.27 mandates security-by-design principles (including distrust external input, data validation/sanitization, secure architecture layers, and design reviews against attack patterns) that reach injection when applied to output construction; this stops exploitation for a minority slice (e.g. where principles drive sanitization) but leaves most code-level injection defects untouched without further implementation rigor.
Secure coding standards require proper neutralization of special elements, directly addressing CWE-74.
Hardening callouts derived
DISA STIG baselines are authored against specific weaknesses. Where this CVE cites a broad weakness class, the mapping is not asserted at that abstraction (owner ruling, 2026-09-25: grade only at Base and below), so no rule is shown here rather than a rule shown against the wrong grain.
- No fine-grained STIG row for CWE-74, a class-level weakness, and none of its children carries one either.