CVE-2023-50290

What it actually does

Apache Solr 9.0.0 through versions before 9.3.0 can expose host environment variables through the Solr Metrics API. The endpoint is intended for operational telemetry and is guarded by the Solr `metrics-read` permission when authorization is enabled, but affected versions included environment variables in the metrics output by default. Because environment variables often contain credentials, API keys, tokens, database connection strings, cloud metadata, proxy secrets, or deployment configuration, a user with Metrics API access can retrieve sensitive data that was not meant to be disclosed. The flaw does not directly allow code execution, data modification, or denial of service, but it can provide credentials that enable follow-on compromise.

Why it matters to the business

The primary risk is credential and secret exposure from Solr hosts. If secrets are stored in environment variables, an attacker or low-privileged internal user with access to the Metrics API may obtain keys that allow access to databases, cloud services, message queues, CI/CD systems, storage buckets, or other connected services. Although this is not listed in CISA KEV and is not marked as ransomware-associated, the EPSS score is high and exploit maturity is reported as weaponized, so exposed Solr metrics endpoints should be treated as a priority. The issue is especially impactful in containerized and cloud deployments where environment variables commonly carry application secrets.

How an attack unfolds

An attacker first identifies an Apache Solr instance and checks whether the Metrics API is reachable over the network. If Solr authorization is disabled, misconfigured, or if the attacker has obtained credentials for an account with the `metrics-read` permission, the attacker sends requests to the Metrics API, such as `/solr/admin/metrics`, and retrieves the returned metrics payload. In vulnerable versions, that response can include environment variables available to the Solr process or host. The attacker then searches the response for high-value values such as passwords, tokens, cloud access keys, database URLs, service account credentials, and internal hostnames. Those secrets can then be reused to access downstream systems, escalate privileges, move laterally, or persist outside Solr. Because the activity may look like normal monitoring traffic, exploitation can be missed unless Metrics API access is logged and reviewed carefully.

How to fix it

Upgrade Apache Solr to version 9.3.0 or later, where environment variables are no longer published through the Metrics API. For package-managed systems, also apply the relevant vendor security updates; the provided package metadata lists Debian 11 `linux` fixed in version `5.10.221-1`, but the product-level fix for this vulnerability is Apache Solr 9.3.0 or later. Until Solr can be upgraded, restrict access to Solr administrative and metrics endpoints, require authentication and authorization, remove unnecessary `metrics-read` permissions, place Solr behind trusted network controls, and block unauthenticated internet access to `/solr/admin/metrics` and related API paths. Review deployments for secrets stored in environment variables and rotate any credentials that may have been exposed. Prefer dedicated secret management systems over long-lived secrets in process-wide environment variables.

How to confirm the fix worked

Confirm that all Apache Solr nodes are running version 9.3.0 or later. Query the Metrics API from an authorized test account and verify that environment variables are no longer present in the response. Confirm that unauthenticated users and users without `metrics-read` cannot access metrics endpoints. Review Solr security configuration to ensure authorization is enabled where appropriate and that only trusted monitoring identities have metrics access. Scan externally and internally reachable Solr endpoints to verify that `/solr/admin/metrics` and related API paths are not exposed to untrusted networks. Where Debian 11 package tracking is used, confirm the relevant package inventory reflects the fixed vendor version `5.10.221-1` where applicable, while separately validating the deployed Solr version.

Typical attack path

1. Discover an exposed or internally reachable Apache Solr service.
2. Determine whether the Solr Metrics API is accessible anonymously or with available credentials.
3. Authenticate as, compromise, or abuse a user or service account that has the `metrics-read` permission, if authorization is enabled.
4. Request Solr metrics endpoints such as `/solr/admin/metrics` and collect the JSON response.
5. Search the metrics output for environment variables containing secrets, credentials, tokens, database connection strings, or cloud keys.
6. Use the exposed secrets to access connected services or cloud resources.
7. Attempt lateral movement, privilege escalation, data theft, or persistence using the recovered credentials.

How to detect it

To determine whether this was already exploited, review HTTP access logs from Solr, reverse proxies, ingress controllers, load balancers, API gateways, and WAFs for requests to Solr Metrics API endpoints, especially `/solr/admin/metrics` and `/api/cluster/metrics`. Focus on HTTP 200 responses, large response sizes, repeated requests, requests from non-monitoring IP addresses, unusual user agents, and access by accounts that should not need metrics visibility. Review Solr authentication and authorization logs for successful logins or permission checks involving `metrics-read`. If metrics responses may have been captured by logging, packet capture, APM tooling, or debugging proxies, search for sensitive environment-variable names in those artifacts. Because exploitation yields secrets rather than a local file artifact, also investigate downstream use of exposed credentials: cloud audit logs, database login logs, object storage access logs, CI/CD audit events, container registry activity, and identity provider logs should be checked for unusual access after any suspicious Metrics API request. Treat any credential present in affected Solr environment variables as potentially compromised if the Metrics API was reachable by untrusted users.

• GET /solr/admin/metrics
• POST /solr/admin/metrics
• /solr/admin/metrics?
• /api/cluster/metrics
• metrics-read
• registry=solr.jvm
• group=jvm
• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• GOOGLE_APPLICATION_CREDENTIALS
• AZURE_CLIENT_SECRET
• DATABASE_URL
• JDBC_URL
• DB_PASSWORD
• MYSQL_PASSWORD
• POSTGRES_PASSWORD
• REDIS_PASSWORD
• VAULT_TOKEN
• KUBERNETES_SERVICE_HOST
• JWT_SECRET
• SECRET_KEY
• API_KEY
• ACCESS_TOKEN

What your security team should do

• Inventory all Apache Solr deployments and prioritize any running Solr 9.0.0, 9.1.x, or 9.2.x for upgrade to 9.3.0 or later.
• Immediately restrict network access to Solr admin and metrics endpoints, especially from the internet and broad internal networks.
• Audit Solr users, roles, and service accounts with the `metrics-read` permission and remove access that is not strictly required.
• Search recent Solr, reverse proxy, load balancer, and WAF logs for successful requests to Metrics API endpoints, especially from non-monitoring clients.
• Rotate credentials, tokens, cloud keys, and database passwords that were present in environment variables on affected Solr hosts.
• Review cloud, database, CI/CD, and secret-store audit logs for suspicious activity using credentials that may have been exposed.
• Update hardening standards to avoid storing long-lived secrets in process-wide environment variables where possible.
• Add SIEM detections for unexpected access to Solr Metrics API paths and for high-volume metrics scraping behavior.