CyberSecBulletin
CVE-2026-114611NVD status: Deferred

OCO-Server: Improper Certificate Validation

CVE-2026-114611 is a critical-severity improper certificate validation vulnerability in OCO-Server from Schorschii, with a CVSS 3.1 base score of 9.1 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected OCO-Server versions: < 1.2.3. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.32% chance of exploitation within 30 days, which is low compared with other CVEs.

Patch this week

Critical severity: a successful attack would have severe impact.

What to do

  1. Check which version of OCO-Server you run against the affected versions below, and install the vendor's latest release.
  2. Read the advisory on github.com for workarounds and exact fixed builds.
  3. Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.

Affected products and versions

VendorProductAffected versionsFixed in
SchorschiiOCO-Server< 1.2.3Not stated

Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.

How the severity score breaks down

Attack vector
NetworkCan be exploited remotely over a network, including the internet.
Attack complexity
LowNo special conditions are needed; the attack works reliably.
Privileges required
NoneNo account or login is needed.
User interaction
NoneNo action by a victim is required.
Scope
UnchangedImpact stays within the vulnerable component.
Confidentiality
HighAll data handled by the component can be read.
Integrity
HighData or code can be modified at will.
Availability
NoneAvailability is not affected.

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. Scored by CNA (github.com).

Official description

OCO-Server is a self-hosted endpoint management application for computer inventory, software deployment, and mobile device management. Prior to 1.2.3,the Apple MDM enrollment endpoint `frontend/api-mdm.php` verifies the signed enrollment-request plist with `openssl_pkcs7_verify(..., PKCS7_NOVERIFY, ...)`. `PKCS7_NOVERIFY` disables signer certificate chain and trust validation, so the signature only has to be self-consistent with whatever certificate is embedded in the PKCS#7 blob. A self-signed certificate from an unrelated attacker is accepted. Because the endpoint trusts the `SERIAL` field taken from the unverified payload, anyone who knows a registered device's serial number can sign a forged plist (`SERIAL` = victim device, attacker-chosen `UDID`) with an arbitrary self-signed certificate; POST it unauthenticated to `/api-mdm.php/profile` (Content-Type: `application/pkcs7-signature`); and receive the victim device's freshly minted MDM identity: a certificate with `CN=<serial>` issued by the server's internal MDM device CA, bundled with its private key in a PKCS#12 payload inside the returned `.mobileconfig` enrollment profile. Additionally, the victim's `mobile_device` database row is silently overwritten with the attacker-supplied `UDID` (device-record hijack). With the stolen certificate and key, the attacker can impersonate the victim device on all subsequent MDM traffic (`/checkin`, `/mdm`, `/parameters`), which authenticate callers by the certificate CN (the serial number) via `checkSignature()` in the same file. This yields control over the victim device's MDM relationship: reading its management data, replacing its push token, and disrupting or redirecting its enrollment. Version 1.2.3 fixes the issue.

Source: the CVE record as published by its numbering authority, via NVD and CVE.org.

The underlying weakness: Improper Certificate Validation

The product does not validate, or incorrectly validates, a certificate.

How developers prevent this class of flaw

  • Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
  • If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

More Improper Certificate Validation vulnerabilities (CWE-295)

Timeline

  1. CVE record published.
  2. CISA published its SSVC assessment (exploitation: poc, automatable: yes, technical impact: total).
  3. Record last changed materially (score, affected products, status or references).

References

Other vulnerabilities in OCO-Server

All OCO-Server vulnerabilities

Recent Improper Certificate Validation vulnerabilities

Spotted an error? Tell us.