CVE-2026-71268

CVE-2026-71268 in OpenPLC's compile_program() function allows authenticated attackers to write arbitrary files via path traversal in parsed .st file content. What's notable isn't that path validation was missing — it's that it exists elsewhere in the codebase (validate_file_path in credentials.py) and simply wasn't connected to this sink. One developer protected a file operation in credentials.py; the identical operation in openplc.py received nothing. If you're defending OpenPLC instances: the hardcoded credentials (openplc:openplc) mean this vulnerability is exploitable immediately upon authentication — no session hijacking or chaining required. The CVSS 9.9 reflects this severity. However, the low EPSS score suggests automated mass-scanning won't find this quickly; the exploitation path requires both credentialed access AND knowledge of the file-write sink, making this a targeted threat rather than worm bait. Audit your OpenPLC deployment for other file-write operations. The presence of validate_file_path() elsewhere indicates the development team knew path traversal was a risk — but applied that knowledge locally rather than architecturally. Check whether other modules handling user-supplied input (configuration loading, project file import, HMI asset handling) invoke any validation at file I/O boundaries. The pattern likely repeats. If you're maintaining OpenPLC code: treat this as a class vulnerability, not an instance. Path traversal from parsed input has appeared repeatedly in ICS/SCADA tooling. The fix isn't just applying validate_file_path() to compile_program() — it's auditing every file-write operation in the codebase for input validation, because partial security awareness applied to an unmapped attack surface is exactly how these gaps propagate.

Reviewed through automated stages and approved by a human before publication.