CVE-2025-27820¶
WSO2 Products impacted: no
Customer action required: no
REPORTED VULNERABILITY¶
A bug in the public-suffix-list (PSL) validation logic in Apache HttpClient 5.4.x disables domain checks, affecting cookie management and hostname verification. Fixed in the 5.4.3 release.1
REPORTED PRODUCTS¶
- WSO2 Identity Server : 7.3.0
WSO2 JUSTIFICATION¶
The Apache HttpClient 5.4.1 distribution shipped with WSO2 Identity Server is within the affected range, and the defect is present in the shipped bytecode: PublicSuffixMatcherLoader.getDefault still resolves the suffix list through the pre-fix relative resource path and falls back to a matcher that knows only the com suffix.
The certificate-validation path this CVE describes is nevertheless never constructed in the product:
The degenerate matcher never reaches hostname verification. The matcher influences certificate checking only through the single-argument DefaultHostnameVerifier constructor. Across the shipped distribution there are three consumers of these classes outside HttpClient itself, and each is accounted for: the Carbon HTTP client utilities and the AWS SNS SDK both construct DefaultHostnameVerifier with the no-argument constructor, which passes a null matcher and skips the public-suffix test entirely; the Yubico WebAuthn bundle imports none of these packages and binds to its own nested HttpClient distribution.
The default verifier is never taken. Nothing in the product reaches HttpsSupport.getDefaultHostnameVerifier, the only certificate-side caller of the defective loader. The Carbon CustomTlsStrategy and the AWS SDK's SdkTlsSocketFactory each pass an explicit verifier into DefaultClientTlsStrategy.
The improper certificate validation therefore cannot occur, because the wildcard-versus-public-suffix check that the defect corrupts is not part of any hostname verification the product performs.
Cookie-domain filtering. The degenerate matcher does still reach cookie-domain filtering through the default cookie-spec registry, so the domain check that would normally stop a host from setting a cookie across a public suffix is weakened on HttpClient-issued requests. Exploiting this requires the product to accept cookies from a host that is in a position to set them for an unrelated domain, and the outbound HttpClient connections the product makes are to endpoints configured by the deployment, not to arbitrary or untrusted hosts. This is a weaker and different exposure than the improper certificate validation the CVE reports, and it is not corrected by upgrading the HttpClient distribution alone. WSO2 is tracking the cookie-management behaviour separately, and will issue an update if any product flow is found to accept cookies from an untrusted host.
Based on this evidence, we conclude that the improper certificate validation reported in this CVE does not pose a security risk to the impacted versions of WSO2 products listed above.