Is CVE-2018-20062 (ThinkPHP “noneCms” Remote Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2018-20062 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. ThinkPHP "noneCms" contains an unspecified vulnerability that allows for remote code execution through crafted use of the filter parameter. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

For a CVE like this, “in the wild” does not mean theoretical exploitability or a proof-of-concept posted online. It means defenders have credible evidence that attackers are actively using the flaw against real systems. For practitioners, that distinction matters because it shifts the issue from routine patch planning to urgent exposure reduction, verification, and post-compromise review.

Because CISA has placed the CVE in its Known Exploited Vulnerabilities catalogue, you should treat it as an active exploitation problem, not just a vulnerability management item. The right immediate question is whether your specific ThinkPHP noneCms deployment is exposed, reachable, and already showing signs of abuse.

Any exploitation-driven response should begin with asset confirmation and dependency mapping. If the affected application is internet-facing, is embedded in a larger portal, or is used as a shared platform component, the blast radius can be wider than a single host. That makes this closer to an exposure problem than a one-off patching task.

How the ThinkPHP noneCms RCE becomes operationally dangerous

The vulnerability matters because remote code execution changes the attacker’s position from external requester to active system operator. Once code execution is possible through crafted use of the filter parameter, the exploit path can support webshell deployment, data theft, command execution, lateral movement, or follow-on credential harvesting depending on the host’s privileges and surrounding trust relationships.

For that reason, the highest-risk systems are not just the ones with the vulnerable package installed, but the ones that expose the application to untrusted network traffic and run it with excessive OS or service privileges. If the application can reach internal services, secrets stores, or administrative interfaces, exploitation can quickly become a broader compromise.

Use the vendor advisory and the CISA KEV catalogue for authoritative version and remediation details, then verify the specific deployment state in your environment before assuming the issue is closed. CISA Known Exploited Vulnerabilities Catalog and NIST National Vulnerability Database are the fastest references for tracking the record and its public metadata.

What to do when patching cannot happen immediately

If remediation is delayed, the objective is to reduce exposure, not to pretend risk has gone away. Restrict network reachability, remove or disable the exposed application path where possible, and place the system behind compensating controls that limit unsolicited requests. If the product is exposed to the internet, treat temporary containment as a short-lived exception, not a stable control.

Because active exploitation is already known, compensating controls should be paired with compromise hunting. Review web logs, process creation, suspicious outbound connections, unexpected file writes, and signs of command execution or webshell staging. If the host has been reachable during the exploitation window, assume the attacker may have tried multiple payloads before success.

Where the application touches authentication material, session state, API keys, or backend credentials, rotate the relevant secrets if you find evidence of post-exploitation access. The point is not to rotate everything blindly, but to rotate anything that could plausibly have been exposed through system-level execution on the affected host.

Risk and Threat Considerations

This CVE carries direct exploitation risk because remote code execution on a public application can convert a routine web vulnerability into full host compromise. The practical danger is highest where the application is externally reachable, poorly monitored, or allowed to interact with sensitive internal systems.

Failure mechanism: Attackers abuse the vulnerable filter parameter to trigger arbitrary code execution, then use that foothold to stage persistence, execute commands, or pivot into adjacent systems.

Impact: Successful exploitation can expose data, disrupt the service, enable lateral movement, and create follow-on credential or secret theft if the host is trusted by other systems.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-1 — Inventory and Control of Enterprise Assets	Asset inventory is needed to find exposed ThinkPHP noneCms instances quickly.
	CIS-7 — Continuous Vulnerability Management	This is an actively exploited CVE that requires urgent prioritisation and remediation.
Recommendation — Identify every reachable host running the affected application and remove unknown exposures. Prioritize the KEV-listed flaw for immediate remediation and verify closure with rescans.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Active exploitation demands prompt flaw remediation and verification on exposed systems.
	IR-4 — Incident Handling	Known exploitation requires compromise assessment and response if abuse is suspected.
Recommendation — Patch or mitigate the vulnerable application and confirm the fix is actually deployed. Investigate for exploitation indicators and escalate to incident response when evidence appears.
OWASP ASVS	V4 — API and Web Service	The exploit is reached through web request handling and input-driven server execution.
Recommendation — Review web request handling and restrict any input path that can trigger server-side execution.

Practitioner Guidance

What to verify: Confirm whether the ThinkPHP noneCms instance is internet-facing, whether it is still reachable, and whether any logs or telemetry show suspicious requests around the KEV listing date and after. If you cannot prove exposure has been absent, treat the host as potentially probed.

Decision rule: If the application is still live and cannot be patched immediately, prioritize containment and compromise assessment before any longer-term hardening work. If evidence of exploitation exists, escalate to incident response and rotate any credentials or tokens that the host could access.

Practitioner takeaway: For KEV-listed RCEs, the key judgement is whether you are responding to a vulnerability or to a likely intrusion path, because that determines whether patching alone is enough.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org