GHSA-wgx6-g857-jjf7
HIGHGHSA-wgx6-g857-jjf7 is a high-severity (CVSS 8.1) CWE-620 vulnerability in openc3. O3 Security confirms whether GHSA-wgx6-g857-jjf7 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenC3 COSMOS: Hijacked session token can be used to reset password for persistence
Blast Radius
openc3💎openc3Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects RubyGems packages — download data is not available via public APIs for these ecosystems.
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
- Attacker is logged in user account with hijacked valid session token, but not knowing the actual password
- Legitimate user, as preventive action, changes his password (password123) using old password (password), that he knows, then establishes new session
- 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 <img width="912" height="479" alt="image" src="https://github.com/user-attachments/assets/d27b5980-0326-40f8-bb39-657d7b1c95a0" />
Impact
Persistence of an attacker who obtained valid session token and preventing legitimate users from account access
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 💎RubyGems | openc3 | all versions | 6.10.5 |
| 💎RubyGems | openc3 | ≥ 7.0.0.pre.rc1&&< 7.0.0-rc3 | 7.0.0-rc3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openc3. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update openc3 to 6.10.5 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wgx6-g857-jjf7 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wgx6-g857-jjf7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wgx6-g857-jjf7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wgx6-g857-jjf7 in your dependencies?
O3 detects GHSA-wgx6-g857-jjf7 across RubyGems dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.