GHSA-r68h-jhhj-9jvm

What it actually does

This advisory concerns the deprecation and planned removal of the ESAPI Validator.isValidSafeHTML API in org.owasp.esapi:esapi, with fixed/updated ESAPI versions available at 2.6.0.0. The primary technical risk is continued reliance on a deprecated HTML safety validation method that may no longer receive the same long-term support, behavior guarantees, or security hardening as replacement approaches. Applications that depend on this method for untrusted HTML handling may face future compatibility failures when the method is removed, and may also retain an outdated content-validation pattern that should be reviewed for cross-site scripting and unsafe HTML handling assumptions. The included pyjwt Ubuntu 16.04 LTS package entry appears unrelated to the ESAPI safe-HTML deprecation and should be validated separately against operating-system package advisories.

Why it matters to the business

The main business risk is application fragility and security debt rather than a confirmed, weaponized exploit path. Systems that depend on deprecated ESAPI safe-HTML validation may break during future library upgrades or continue using outdated input-validation logic for user-supplied HTML. Because this advisory was published in 2023 and has been available for a long period, unresolved usage indicates backlog risk and may complicate secure software maintenance, compliance evidence, and dependency modernization efforts. There is no CISA KEV listing, no known ransomware association, and no stated exploit maturity, so prioritization should be based on whether affected applications accept or render user-controlled HTML in sensitive workflows.

How an attack unfolds

There is no public indication from the provided data that this advisory represents an actively exploited vulnerability with a specific exploit procedure. A realistic abuse scenario would depend on an application using Validator.isValidSafeHTML as a gatekeeper for user-supplied HTML and then rendering that content to other users. An attacker would identify an input field or API that accepts HTML, submit crafted markup designed to bypass or stress the application's validation assumptions, and attempt to have the content rendered in a victim's browser. If the application incorrectly treats the deprecated validation result as sufficient protection, the attacker may be able to trigger script execution, content injection, or other unsafe rendering behavior depending on the surrounding application code and output encoding. Separately, once the API is removed, attackers do not need to exploit the method directly; the risk becomes operational if teams avoid upgrading security libraries because application code still depends on the deprecated API.

How to fix it

Upgrade org.owasp.esapi:esapi to version 2.6.0.0 or later where available, and remove application dependencies on Validator.isValidSafeHTML before the API is deleted. Replace deprecated safe-HTML validation with a maintained HTML sanitization strategy appropriate for the application, such as a current allowlist-based sanitizer, strict output encoding, and contextual escaping at render time. Review all code paths that accept, store, transform, or render user-supplied HTML and ensure validation is not the sole control for browser safety. For Ubuntu 16.04 LTS systems where pyjwt is in scope, update pyjwt to 1.3.0-1ubuntu0.1 or later from the appropriate vendor repository, but treat this as a separate package-maintenance action unless confirmed by the relevant OS advisory. Remove duplicate or stale dependency declarations and ensure transitive dependency management resolves to the fixed ESAPI version.

How to confirm the fix worked

Confirm dependency resolution shows org.owasp.esapi:esapi version 2.6.0.0 or later in build output, lockfiles, SBOMs, and runtime artifacts. Search source code for calls to Validator.isValidSafeHTML and verify they have been removed or replaced with maintained sanitization and output-encoding controls. Run unit and integration tests covering rich-text, HTML input, and rendering workflows, including malicious and malformed markup. Use software composition analysis to verify no vulnerable or deprecated ESAPI version remains in direct or transitive dependencies. For systems tracking Ubuntu packages, confirm the installed pyjwt package version is 1.3.0-1ubuntu0.1 or later where applicable. Finally, perform browser-based security testing against any feature that renders user-controlled content to confirm script execution and unsafe markup are blocked.

Typical attack path

1. Identify an application feature that accepts user-controlled HTML or rich-text content.
2. Determine whether the application relies on ESAPI Validator.isValidSafeHTML or similar legacy validation logic before storing or rendering that content.
3. Submit crafted HTML payloads that attempt to bypass validation assumptions, such as unusual tags, attributes, encodings, nested markup, or malformed input.
4. Cause the stored or reflected content to be rendered by another user or privileged operator.
5. If validation and output encoding are insufficient, execute browser-side actions in the victim context, such as session abuse, data access, or unauthorized actions.
6. Maintain pressure on the target's dependency posture by exploiting the fact that deprecated API usage may delay upgrades to newer library versions.

How to detect it

There are no specific public exploitation indicators in the provided advisory data. To determine whether unsafe behavior has already occurred, focus on application features that accept or render user-generated HTML. Review web application logs, API gateway logs, WAF events, content-submission records, and application audit trails for attempted script injection, unusual HTML tags or attributes, encoded markup, malformed nested markup, and repeated probing of rich-text fields. Investigate any stored content containing script-capable constructs that was later viewed by other users, especially administrators or support personnel. Correlate suspicious submissions with subsequent user sessions, authentication events, privilege changes, unexpected requests from victim browsers, or reports of browser pop-ups, redirects, or unauthorized actions. On the software side, examine source repositories, build logs, dependency manifests, SBOMs, and runtime classpaths for continued ESAPI versions below 2.6.0.0 and direct references to Validator.isValidSafeHTML. Because no concrete exploit payload or actor-specific infrastructure is provided, detection should be behavior-based rather than IOC-only.

What your security team should do

• Inventory applications using org.owasp.esapi:esapi and prioritize those that accept or render user-supplied HTML.
• Upgrade ESAPI dependencies to 2.6.0.0 or later and ensure build tooling resolves the fixed version at runtime, not only in source manifests.
• Open engineering tickets to remove all uses of Validator.isValidSafeHTML because it is deprecated and scheduled for deletion.
• Review rich-text and HTML-rendering features for cross-site scripting risk, including stored, reflected, and DOM-based rendering paths.
• Add static analysis or code-search checks that fail builds when deprecated ESAPI safe-HTML APIs are introduced.
• Validate whether the pyjwt Ubuntu 16.04 LTS package entry is relevant to supported assets, and update to 1.3.0-1ubuntu0.1 or later where present.
• Because this is not KEV-listed and has no stated exploit maturity, prioritize remediation based on exposure of HTML input features and dependency upgrade blockers rather than emergency incident response.
• Document the migration path so future ESAPI upgrades do not break application builds when the deprecated API is removed.