Apache Juneau Fixes XSS and Sensitive Header Logging

What happened

Apache has fixed sensitive logging and cross-site scripting issues in Apache Juneau. Think of them as a receptionist copying private visitor credentials into a shared notebook and a noticeboard displaying submitted text without safely handling its contents. The flaws involve different parts of an application, but both concern information being handled unsafely.

The logging flaw, CVE-2026-73100, affects the default REST server call logger. When a request ends in a server error, the logger records request headers without hiding sensitive values. The cross-site scripting flaw, CVE-2026-96677, affects HTML page generation when an application puts request-derived values into surrounding page elements, such as its header, navigation area, sidebar or footer.

Apache's advisory identifies versions earlier than 9.2.1 as affected and 9.2.1 and later as fixed. NVD published entries for the vulnerabilities on 2026-11-05. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-11-06. Neither CVE was listed in the Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog, or CISA KEV, as of the catalog check; that status does not establish whether exploitation has occurred.

Technical details

CVE-2026-73100 is classified as CWE-532, Insertion of Sensitive Information into Log File. The root problem is missing redaction in the default REST server call logger: headers accompanying a request that ends in a server error are written to the application log in cleartext, meaning their values remain readable. Sensitive headers include Authorization, Cookie, Proxy-Authorization and X-API-Key.

The logging issue requires a request that produces a server error. A client able to trigger that condition can cause the request's headers to be logged, but reading the resulting sensitive values requires access to the logs. The distinction matters: causing a log entry and obtaining its contents are separate conditions. A request must also contain sensitive header values for those values to be exposed through this behavior.

CVE-2026-96677 is classified as CWE-79, Improper Neutralization of Input During Web Page Generation, commonly called cross-site scripting or XSS. HTML serialization—the process of turning application content into an HTML document—does not safely encode variable substitutions in the page's surrounding layout, called its chrome. Encoding makes inserted values display as text instead of allowing them to be interpreted as page content. Applications become affected when they place request-derived variables, including header, form or path values, into those fields. The default chrome does not use request variables, so this XSS condition applies to applications that add them.

NVD lists a CVSS version 4.0 score of 10.0 and a CRITICAL severity rating for each CVE. CVSS, the Common Vulnerability Scoring System, describes technical severity; it does not measure how often a flaw is exploited or prove that a particular application meets its prerequisites. For Juneau, those prerequisites include error-triggered header logging for CVE-2026-73100 and request-derived variables in page chrome for CVE-2026-96677.

Weakness types: Cross-site scripting (XSS)

Who is affected

Everyday users

For everyday users, the relevant software is the Apache Juneau application operated by a service provider or organization. Sensitive request headers may contain authentication information. If those headers reach the application log after a server error, people who can read that log may also be able to read the recorded values.

The browser-facing issue depends on how the application was built. An application that includes request-derived values in its page chrome can reflect those values without safe encoding, allowing XSS. Juneau's default chrome does not meet that condition. Users who do not manage the application should direct update questions to its operator.

Developers

Developers should review their Juneau dependency version and any customization of the HTML page chrome. Pay particular attention to substitutions that draw from request headers, form data or path values. The relevant question is whether those values enter header, navigation, aside, footer or similar fields during HTML serialization.

Review the logging path separately. An application can avoid the XSS precondition by using the default chrome and still need the logging fix. For requests handled by the default REST server call logger, determine whether server errors can leave sensitive headers in logs and who can read those records.

Server and IT admins

Server and IT admins should identify deployed Apache Juneau versions and plan updates for installations earlier than 9.2.1. The logging issue also makes application log access relevant: records produced by failing requests may contain readable authentication headers, so access to those records deserves review.

Assess the flaws independently when coordinating with application owners. A developer may need to confirm whether customized page chrome uses request variables, while an administrator can help establish which deployments use an affected release and how application logs are accessed. Neither a severity score nor catalog status replaces that deployment-specific review.

What to do now

1. Identify applications and deployments using Apache Juneau, and confirm whether their versions are earlier than 9.2.1.
2. Update affected deployments to 9.2.1 or later. Follow the update steps in the vendor's advisory.
3. Review customized HTML page chrome for request-derived variables, including substitutions sourced from headers, form data or path values.
4. Review use of the default REST server call logger and assess whether server-error requests could have recorded sensitive header values.
5. Review access to potentially affected application logs and handle any exposed authentication information through your organization's credential-management process.
6. After deployment, confirm the running application uses the fixed release and verify the relevant logging and page-generation behavior in a controlled environment.

If you can't update yet

• Check the vendor advisory for applicable interim guidance on restricting access to application logs that could contain sensitive request headers.
• Check the vendor advisory for applicable interim guidance on restricting access to affected applications and reducing their internet exposure while an update is pending.

How to confirm the fix

• Confirm the deployed application is running Apache Juneau 9.2.1 or later; checking only a planned dependency change does not establish what is running.
• In a controlled environment, use non-sensitive test header values to verify that requests ending in server errors no longer leave sensitive header contents readable in logs.
• For applications with request-derived variables in page chrome, verify that those substitutions are safely HTML-encoded and displayed as text.

NVD scores and CISA KEV status

As of November 6, 2026, none of these CVEs is listed in the CISA Known Exploited Vulnerabilities catalog.

Affected products and fixed versions 2 rows

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

References

• Apache advisory: https://lists.apache.org/thread/j05q7vw08j48o96tdlzcsd4sozx1lyl6
• NVD: CVE-2026-73100
• NVD: CVE-2026-96677
• CISA Known Exploited Vulnerabilities catalog
• Also reported by KISA (Korea Internet & Security Agency) on November 6, 2026: KISA advisory (Korean)

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.