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.