CVE-2022-29958
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedJTEKT TOYOPUC PLCs through 2022-04-29 do not ensure data integrity. They utilize the unauthenticated CMPLink/TCP protocol for engineering purposes, including downloading projects and control logic to the PLC. Control logic is downloaded to the PLC on a block-by-block basis with a given memory address and a blob of machine code. The logic that is downloaded to the PLC is not cryptographically authenticated, allowing an attacker to execute arbitrary machine code on the PLC's CPU module in the context of the runtime. In the case of the PC10G-CPU, and likely for other CPU modules of the TOYOPUC family, a processor without MPU or MMU is used and this no memory protection or privilege-separation capabilities are available, giving an attacker full control over the CPU.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceJTEKT TOYOPUC PLCs use an unauthenticated CMPLink/TCP protocol for engineering operations that downloads control logic block-by-block with memory addresses and machine code. Since the downloaded logic lacks cryptographic authentication, attackers can send malicious machine code that executes directly on the PLC CPU without integrity verification. Certain CPU modules (e.g., PC10G-CPU) lack MPU/MMU hardware protection, providing attackers full control over the CPU.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE dataall versionsall versionsall versionsall versionsall versionsall versionsall versionsall versionsCVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Network
- Complexity
- Low
- Privileges
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Identify JTEKT TOYOPUC PLC modelReview PLC hardware documentation, engineering software project files, or physical PLC unit labeling to determine if the model matches any of the affected variants: PC10G-CPU, PC10GE, PC10P, PC10P-DP, PC10P-DP-IO, PC10B-P, PC10B, or PC10E.Affected if The installed PLC model is one of the eight listed variants.
-
Verify CMPLink/TCP protocol is enabledCheck the PLC network configuration or engineering software settings for CMPLink/TCP protocol configuration. This protocol is used for engineering operations and block-by-block logic downloads.Affected if CMPLink/TCP protocol is enabled and configured for communication with the PLC.
-
Confirm firmware version and TCC numberAccess the PLC firmware information through the engineering software or boot diagnostic screen. Look for the TCC number (e.g., TCC 6353, TCC 6464, TCC 6372, etc.) matching the affected product list.Affected if The firmware TCC number matches any of the listed versions (6353, 6464, 6372, 6726, 6752, 6373, 1021, 4737).
-
Assess network exposure of engineering portsReview network firewall rules or PLC network configuration to determine if the CMPLink/TCP port (typically port 2007/TCP or similar engineering port) is accessible from untrusted networks or unauthorized stations.Affected if The CMPLink/TCP port is accessible from outside the trusted engineering station subnet.
-
Identify CPU module hardware protectionCheck the PLC CPU module model number and specifications. Specifically determine if the module is a PC10G-CPU or similar variant that lacks MPU/MMU hardware protection features.Affected if The CPU module is a PC10G-CPU or other variant without MPU/MMU hardware protection.
A user is affected if they have any of the listed JTEKT TOYOPUC PLC models with CMPLink/TCP enabled and the firmware TCC number matches the affected versions, particularly if the CPU module lacks hardware protection or the engineering port is network-exposed.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scopedImplement cryptographic authentication for the CMPLink/TCP protocol to verify integrity of downloaded logic; isolate PLCs behind network segmentation; restrict engineering access to authorized stations via IP filtering or VPN.
- Implement network segmentation to isolate the affected PLCs from untrusted networks using firewalls or VLANs
- Place the TOYOPUC PLCs behind a DMZ and restrict access to engineering stations only
- Implement network monitoring to detect unauthorized CMPLink/TCP traffic on port 2000/2001
- If possible, disable CMPLink/TCP protocol access from external networks and limit engineering access to dedicated management networks
- Apply compensating controls such as physical access controls to prevent unauthorized access to PLC hardware
- Audit all project downloads and control logic changes to detect unauthorized modifications
- Consult JTEKT directly for any available firmware updates or security patches for these specific CPU modules (TCC 6353, 6464, 6372, 6726, 6752, 6373, 1021, 4737)
Generated from the published advisory — verify against the referenced sources before acting.
- Consultation8.0 h
- Implementation40.0 h
- Testing24.0 h
- Review / QA12.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $23,296.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2022-29958 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2022-29958 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data