How severe is GHSA-p6cp-6r35-32mh?

GHSA-p6cp-6r35-32mh has a CVSS score of 7.5/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-p6cp-6r35-32mh?

GHSA-p6cp-6r35-32mh affects the following packages: org.xwiki.platform:xwiki-platform-search-solr-api (Maven), org.xwiki.platform:xwiki-platform-search-solr-api (Maven), org.xwiki.platform:xwiki-platform-search-solr-api (Maven). Ecosystems affected: Maven.

How do I fix GHSA-p6cp-6r35-32mh?

Update org.xwiki.platform:xwiki-platform-search-solr-api to 14.10.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p6cp-6r35-32mh is resolved across your whole dependency graph.

How do I detect GHSA-p6cp-6r35-32mh in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.xwiki.platform:xwiki-platform-search-solr-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-p6cp-6r35-32mh if there is no patch (or I can't update yet)?

Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

Is GHSA-p6cp-6r35-32mh actively exploited in the wild?

No public exploit code has been indexed for GHSA-p6cp-6r35-32mh yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-p6cp-6r35-32mh?

GHSA-p6cp-6r35-32mh has an EPSS (Exploit Prediction Scoring System) score of 83.5%, placing it in the 100th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. A score above 50% indicates significantly elevated exploitation risk — immediate patching is strongly recommended.

What type of vulnerability is GHSA-p6cp-6r35-32mh?

GHSA-p6cp-6r35-32mh is classified as Information Exposure (CWE-200), CWE-359 (CWE-359), CWE-312 (CWE-312). These weakness types describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

Is there exploit tooling available for GHSA-p6cp-6r35-32mh?

A Nuclei detection template exists for GHSA-p6cp-6r35-32mh, meaning automated scanners can fingerprint it. Public exploit tooling significantly increases real-world risk — prioritize patching and ensure detection coverage. Exploit tooling should only ever be used in isolated, authorized testing environments.

When was GHSA-p6cp-6r35-32mh published, and has it been updated?

GHSA-p6cp-6r35-32mh was published on December 16, 2023 and was last updated on September 10, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕

☕ Maven

Not in CISA KEV

HIGH severity

Solr search discloses password hashes of all usersGHSA-p6cp-6r35-32mh

HIGHFix: xwiki/xwiki-platform@3e5272f

GHSA-p6cp-6r35-32mh is a high-severity (CVSS 7.5) Information Exposure vulnerability in org.xwiki.platform:xwiki-platform-search-solr-api. EPSS puts its 30-day exploitation probability at 83.5% (100th percentile). A fix is available for org.xwiki.platform:xwiki-platform-search-solr-api — see the affected versions and patch details below.

Also known asCVE-2023-50719

Published

Dec 16, 2023

Updated

Sep 10, 2026

Affected

3 pkgs

Patched

3 / 3

Exploits

None indexed

Exploitation data as of Nov 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-p6cp-6r35-32mh.

EPSS Exploitation Probability

via FIRST.org ↗

83.5%probability of exploitation in next 30 days

Very High Risk0.00%

Lower risk than most CVEs100th percentile — riskier than 100% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

3 pkgs affected

☕org.xwiki.platform:xwiki-platform-search-solr-api☕org.xwiki.platform:xwiki-platform-search-solr-api☕org.xwiki.platform:xwiki-platform-search-solr-api

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Impact

The Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for propertyvalue:?* AND reference:*.password and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable.

By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by CVE-2022-41933, passwords are stored in plain text if they have been set using the password reset feature. This might affect XWiki installations that are using an external authentication mechanism such that passwords aren't stored in the wiki.

This vulnerability also affects any configurations used by extensions that contain passwords like API keys that are viewable for the attacker. Normally, such passwords aren't accessible but this vulnerability would disclose them as plain text.

Patches

This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1. This vulnerability has been patched as part of patching GHSA-2grh-gr37-2283, the part of the fix that changes the indexing of single properties to use the same code as the main document for getting the property's value fixes this vulnerability.

Workarounds

We're not aware of any workarounds apart from upgrading to a fixed version.

References

Affected Packages

3 total 3 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`org.xwiki.platform:xwiki-platform-search-solr-api`	≥ 7.2-milestone-2&&< 14.10.15	14.10.15`org.xwiki.platform:xwiki-platform-search-solr-api:14.10.15`
☕Maven	`org.xwiki.platform:xwiki-platform-search-solr-api`	≥ 15.0-rc-1&&< 15.5.2	15.5.2`org.xwiki.platform:xwiki-platform-search-solr-api:15.5.2`
☕Maven	`org.xwiki.platform:xwiki-platform-search-solr-api`	≥ 15.6-rc-1&&< 15.7-rc-1	15.7-rc-1`org.xwiki.platform:xwiki-platform-search-solr-api:15.7-rc-1`

Affected Products

1 product · 7 configurations

Application

xwikixwiki

≥ 15.0 && < 15.5.2

3 versions

7.215.615.7

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.xwiki.platform:xwiki-platform-search-solr-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.xwiki.platform:xwiki-platform-search-solr-api to 14.10.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-p6cp-6r35-32mh is resolved across your whole dependency graph.
Workarounds
Assume what was exposed is already known: rotate any credential, token or key that the affected component could return, restrict the endpoint to callers that genuinely need it, and strip sensitive fields from responses and error output at the boundary rather than relying on the client not to read them.

How to detect GHSA-p6cp-6r35-32mh

A community-maintained Nuclei template exists for this CVE. You can scan for it directly:

nuclei -id ghsa-p6cp-6r35-32mh -u https://target

Template: XWiki < 4.10.15 - Sensitive Information Disclosure
Severity: high
Impact: Successful exploitation could lead to disclosure of the password hashes of all users.
Remediation: This has been patched in XWiki 14.10.15, 15.5.2 and 15.7RC1.

Template by ProjectDiscovery nuclei-templates (ritikchaddha), MIT licensed. View the full template. Scan only systems you are authorised to test.

Frequently Asked Questions

### Impact The Solr-based search in XWiki discloses the password hashes of all users to anyone with view right on the respective user profiles. By default, all user profiles are public. To reproduce, it is sufficient to search for `propertyvalue:?* AND reference:*.password` and then deselect the "Document" property under "Result type" in the "Refine your search" widget at the right of the search results. If this displays any passwords or password hashes, the installation is vulnerable. By default, passwords in XWiki are salted and hashed with SHA-512. On XWiki versions affected by [CVE-2022-4