Skip to content

OpenC3 COSMOS: Hijacked session token can be used to reset password for persistence

High severity GitHub Reviewed Published Apr 20, 2026 in OpenC3/cosmos • Updated May 29, 2026

Package

bundler openc3 (RubyGems)

Affected versions

< 6.10.5
>= 7.0.0.pre.rc1, < 7.0.0-rc3

Patched versions

6.10.5
7.0.0-rc3

Description

Summary

The OpenC3 password change functionality allows a user to change their password without providing the old password, by accepting a valid session token instead. In assumed breach scenarios, this behaviour can be exploited by an attacker who has already obtained a valid session token, to gain persistence in hijacked account (including admin) and prevent legitimate users from accessing the account.

Details

The design flaw in authentication model (authentication.rb) allows for interchangeable use of password and session tokens for user authentication As old tokens are not revoked upon password reset, an attacker who has obtained a valid session token can continue to authenticate and change the account’s password even after the victim resets it, thereby maintaining persistent control over the compromised account.

PoC

  1. Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
  2. Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
  3. Attacker issues another password change request (in web proxy like Burp) supplying his still valid token as old_password, changing it to attacker-password, from this point preventing any other legitimate users from accessing account

image

image

Impact

Persistence of an attacker who obtained valid session token and preventing legitimate users from account access

References

@ryanmelt ryanmelt published to OpenC3/cosmos Apr 20, 2026
Published to the GitHub Advisory Database Apr 22, 2026
Reviewed Apr 22, 2026
Published by the National Vulnerability Database May 4, 2026
Last updated May 29, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(12th percentile)

Weaknesses

Unverified Password Change

When setting a new password for a user, the product does not require knowledge of the original password, or using another form of authentication. Learn more on MITRE.

CVE ID

CVE-2026-42084

GHSA ID

GHSA-wgx6-g857-jjf7

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.