CVE-2025-68271: Critical Unauthenticated Remote Code Execution in OpenC3 COSMOS via JSON-RPC Eval Abuse

CVE: CVE-2025-68271
Product: OpenC3 COSMOS
Affected Versions: Versions between 5.0.6 up through 6.10.1
Patched Version: 6.10.2 — use this version to fix the problem
Severity: Critical
CVSS Score: 10.0 (Critical)
Exploitability: High — network accessible, no authentication required
Public Exploit: No working public proof-of-concept code published
Official Patch / Upgrade: https://github.com/OpenC3/cosmos/security/advisories/GHSA-w757-4qv9-mghp

What This Vulnerability Is

OpenC3 COSMOS provides a JSON-RPC interface — essentially a way for clients to send commands and parameters to the server in a structured JSON request.

Inside the server code there was a routine that tried to convert string parameters into actual Ruby values. For example, if the JSON parameter looked like an array encoded as a string, the server code would use a Ruby dynamic evaluation mechanism to interpret that string.

The fundamental flaw is that this conversion happened before the server checked whether the user was allowed to make the request.

That means an attacker from the network could send a malicious JSON request with specially crafted parameter text that gets evaluated on the server. Because that evaluation happens before any authentication or authorization check, the attacker effectively gets to run arbitrary code inside the server process.

This kind of flaw — where untrusted input is turned into executable code — is extremely dangerous and leads directly to remote code execution.

Why It’s Serious

There are three key reasons this issue is treated as Critical:

Unauthenticated: The server doesn’t require valid credentials before this vulnerable parser runs. A remote attacker can hit the JSON-RPC endpoint directly.
Remote Code Execution (RCE): The unsafe parsing leads to arbitrary execution — meaning the attacker can run anything they want within the privileges of the COSMOS process.
Network Accessible: The API is typically reachable over standard HTTP/S ports, so no special access is needed.

Worst case, an attacker could take full control of the host, install backdoors, pivot into internal networks, or tamper with the OT/mission infrastructure the system manages.

How It Works

A client (or attacker) sends a JSON-RPC POST request to the COSMOS API endpoint.
The server receives the request and begins parsing it. Some parameters, instead of simple numbers or strings, might look like encoded arrays or code.
The server calls an internal Ruby routine that uses dynamic evaluation. This means it takes a text string and runs it as code inside the Ruby interpreter.
Because this happens before any check of “is this user allowed to do this?”, the attacker’s malicious code runs with full rights of the service process.
After code execution, the server eventually gets to authorization — but it’s already too late.

Can This Be Exploited in the Wild?

At the time of writing:

There is no verified public proof-of-concept exploit code published anywhere.
This vulnerability has been described by the project’s maintainers and fixed.
But because it’s easy to trigger and the evaluation happens before auth, it’s extremely risky if left unpatched.

Even without a public exploit in circulation, systems exposed to the internet or untrusted networks should assume they are at risk.

How Attackers Could Construct a Malicious Request

I will not give working exploit code, but here’s the type of pattern that makes it dangerous:

JSON-RPC normally expects structured well-formed JSON with parameters like numbers, strings, arrays, etc. If an attacker sends a parameter that looks like code tuned to Ruby’s evaluator — for example, something containing backticks or other Ruby expression syntax inside a string — that text can be interpreted as code.

Attackers can supply that in fields where the server didn’t properly restrict content.

How to Detect Possible Exploitation Attempts

Because this flaw is about unsafe evaluation of input, detection revolves around looking for unexpected shapes in JSON requests and anomalous server behavior.

1. Web/API Gateway Logs

Collect:

Full HTTP POST bodies to the JSON-RPC endpoint
Timestamps, source IP, user agent
URI paths and headers

Watch for:

POST requests with suspicious characters in parameter values — backticks, parentheses, unusual punctuation in fields where plain values are expected
Requests where numeric or simple string fields contain structured text

Example patterns:

Parameter containing backticks like `something`
String that looks like code: system() or similar
Content that doesn’t conform to expected numeric or list formats

2. Application Logs

COSMOS level logs should show:

Method names requested
Parameter lists as received
Recording unusual large or nested parameter values

If logging is not capturing bodies, enable detailed request dumps temporarily until patching completes.

3. WAF / Reverse Proxy Alerts

If you use a WAF in front of the API, look for:

Rules that block array-looking strings with unexpected tokens
Sudden spikes in blocked JSON-RPC payloads
Requests that trigger multiple pattern matches

4. Host Activity

On the host running COSMOS:

Sudden spawning of subshells or unexpected child processes
New files appearing in directories where the service does not normally write
Outbound connections originating from the COSMOS host that are unusual
CPU or memory spikes coinciding with API traffic

These may indicate attempted or successful exploitation.

Logging You Should Enable

Log Source	What to Capture	Why It Helps
Web server access logs	POST bodies to JSON-RPC	Surface suspicious parameters
Reverse proxy logs	URI, headers, body snippets	Early filtering
API server logs	Raw request content, method names	Application-level context
Host audit logs (auditd/OS)	New processes, execution events	Detect unwanted execution
EDR / Endpoint monitoring	Process creation, privilege escalation	Catch exploitation attempts

Detection Rules You Can Use

You can build detection rules that look for odd input shapes — for example:

JSON POSTs where a numeric field suddenly contains characters like [ or { that aren’t expected
Fields that contain backticks ` or semicolons ; followed by words that are not part of the API syntax
Long unstructured strings in fields where you normally expect short simple values

You can implement these rules in your SIEM, WAF, or IDS:

Pattern rule example (conceptual):

IF HTTP POST to /jsonrpc
AND request body contains any of: ``, system(, %(  
AND the parameter is supposed to be a simple value
THEN flag as suspicious

Fine-tune with your environment’s naming, expected fields, and typical API use to reduce false positives.

How to Protect and Mitigate

Immediate Actions

Upgrade to version 6.10.2 immediately.
Restrict network access to the JSON-RPC endpoint — only trusted networks or VPN users should have access.
Place a WAF in front of the API to block suspicious patterns while you patch.

Hardening Practices

Run COSMOS under a dedicated, least-privilege account.
Use API rate limiting to slow down probes.
Enable detailed logging to catch unusual requests early.
Implement monitoring rules for process execution on the server.

Testing and Verification

After patching, confirm:

The vulnerable code path is no longer present (server no longer calls unsafe evaluation)
Requests containing malformed or malicious payloads are rejected cleanly
There are no unexplained errors in logs

Key Takeaways

This was a pre-auth remote code execution bug because the server evaluated unsafe input before checking permissions.
It’s critical and easily reachable over the network, even without credentials.
Fixing it requires upgrading to 6.10.2.
Detection relies on logging unexpected input shapes and monitoring for unusual host behavior.
There is no public exploit code your defenders will stumble across — which is good — but it means you must rely on defensive visibility and patching without waiting for proof-of-concept.