Check whether your business runs OpenDock FullCore (and note whether the version is 4.4 or earlier).
If OpenDock FullCore 4.4 or earlier is in use, stop exposing the OpenDock site to the public internet as much as possible (use IP allowlists, VPN-only access, or move behind a firewall/reverse proxy with strict rules).
Look for an OpenDock FullCore upgrade or vendor-migration path that eliminates PHP remote file inclusion via doc_directory (no fixed version is identified in the provided patch info).
If you cannot upgrade soon, treat the system as compromised-risk: restrict all access to the affected endpoints and monitor for unexpected outbound connections and suspicious web requests.
Multiple PHP remote file inclusion vulnerabilities in OpenDock FullCore 4.4 and earlier allow remote attackers to execute arbitrary PHP code via a URL in the doc_directory parameter in (1) sw/index_sw.php; (2) cart.php, (3) lib_cart.php, (4) lib_read_cart.php, (5) lib_sys_cart.php, and (6) txt_info_cart.php in sw/lib_cart/; (7) comment.php, (8) find_comment.php, and (9) lib_comment.php in sw/lib_comment/; (10) sw/lib_find/find.php; and other unspecified PHP scripts.
In plain language
Written by AI from the record
CVE-2006-5392 is a serious OpenDock FullCore flaw where an unauthenticated attacker can make your server load and run attacker-controlled PHP code through the doc_directory setting; if you run OpenDock FullCore 4.4 or older, you should worry and act.
OpenDock FullCore has multiple unauthenticated PHP remote file inclusion issues in scripts that use the doc_directory parameter; a remote attacker can provide a URL/path to cause arbitrary server-side PHP code execution.
If you're affected
Full server compromise
Customer data exposure
Business disruption
Malware or ransomware setup
What is it
Think of this like a website that reads a file location from a setting called doc_directory and then fetches whatever it points to. The vulnerability lets an attacker trick it into loading a remote “PHP plugin” they control. Once that code runs on your server, it can do anything the web server account can do—like stealing data or changing site behavior.
Who is affected
This matters if your business uses OpenDock FullCore version 4.4 or earlier. Because the issue is described as not requiring authentication or user interaction, any exposure of the affected parts of the site to attackers is the main risk.
Reachability gate: there is a risk when the vulnerable OpenDock FullCore functions are reachable over the network (for example, accessible from the public internet or from an untrusted network).
How urgent is it
This is urgent for affected systems because remote attackers can execute arbitrary PHP code without needing a login. Public exploitation is available, and the press attention is rising, so you should assume active interest in this kind of bug.
No fixed upgrade version was identified in the available patch information, so focus first on confirming exposure and immediately reducing network reachability while you work toward a safe upgrade or replacement.
What to do — in detail
Confirm exposure (affected version + reachability)
Identify the exact OpenDock FullCore version running in production.
If it is 4.4 or earlier, assume the vulnerable code paths are present.
Determine whether the OpenDock app is reachable from untrusted networks (internet-facing, shared hosting over the public internet, or accessible from the public side of a firewall).
Check likely vulnerable endpoints
The provided details mention multiple scripts that use doc_directory, including: sw/index_sw.php, cart.php, lib_cart.php, lib_read_cart.php, lib_sys_cart.php, txt_info_cart.php, comment.php, find_comment.php, lib_comment.php, sw/lib_find/find.php, and other unspecified PHP scripts.
In your access logs, look for requests that include a doc_directory parameter or unusual URL/path values.
Upgrade / fix status
Patch availability: no specific fix or fixed version information was provided in the patch findings.
Action: contact the OpenDock FullCore maintainers/vendor or your hosting provider to obtain a version (or alternative deployment) known to remove the remote file inclusion behavior for doc_directory.
If no safe patched version exists, plan a migration away from OpenDock FullCore.
Temporary workaround while waiting for a fix
Reduce exposure immediately: restrict access to the OpenDock server to only trusted IPs/users (VPN-only, IP allowlisting, or strict reverse-proxy rules).
If you can apply web application firewall rules, block requests that contain the doc_directory parameter or block remote URL/path patterns being supplied as parameters.
Validate that the WAF/proxy restrictions are actually enforced (test from an untrusted network).
Monitor after changes
Continue reviewing web server logs for repeated attempts involving doc_directory.
Watch for signs of server-side compromise: unexpected outbound traffic from the web server, new/modified PHP files, abnormal process execution, or unexpected changes to site content.
Technical context
Severity: high (ability to execute arbitrary server-side code). This is a PHP Remote File Inclusion class issue (CWE listed as NVD-CWE-Other in the provided data) caused by the application using an attacker-influenced doc_directory parameter to include external code.
Mechanism and trigger: an attacker supplies a URL/path via doc_directory, which the affected OpenDock FullCore scripts then use to include and execute attacker-controlled PHP.
Authentication and interaction: none required, no user interaction.
Exploitation status: public exploit available (one known). KEV listing was not found in the provided findings. Therefore, treat as actively relevant based on public exploitation availability rather than waiting for KEV confirmation.
EPSS: provided as a prediction with a flat trend; this is not a certainty and is not used as the primary basis for urgency given the availability of public exploitation.
Patch state: no fix/patch information available in the provided findings.
This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.
