☠️
EXFILTRATING
DATA...
01010111 10110010 00101001 11000110 01101100 10011011 00010001 11100101 01000010 10101111
[ <-- BACK_TO_SEARCH ]

CVE-2025-66432

CVE-2025-66432 Security Advisory in Oxide
📅 PUBLISHED: 2025-11-30 00:00 UTC 🔄 UPDATED: 2026-09-23 20:34 UTC
[ OFFICIAL PATCH DEPLOYED ↓ ] FIX: LIKELY — 2 independent sources confirm fix
[ DEFENSE PATCH ↓ ]
💣 PoC: None
👁️
Proof of Concept - Indicates if functional exploit code is publicly available, drastically increasing the risk of immediate attacks.
🎯 EPSS: 0.22%
👁️
0.22% probability
5.6× above the median CVE
Tier: ELEVATED
30-day exploitation window · FIRST.org · updated daily
Patch available — upgrade to latest release
CVSS SEVERITY SCALE
9.0–10.0 CRITICAL
7.0–8.9 HIGH
4.0–6.9 MEDIUM
0.1–3.9 LOW
0.0 NONE
5.0
THREAT LEVEL
■ tracking this CVE ✓ independent patch confirmation ⧗ same-origin mirror (GHSA) ⚠ active exploitation verification policy →

Executive Summary

CVE-2025-66432 is a security advisory affecting the Oxide control plane versions 15 through 17 (before 17.1). The vulnerability allows API tokens to be renewed past their original expiration date, violating the intended security policy. This issue is classified as an Insufficient Session Expiration (CWE-613) weakness, where the system fails to properly enforce token expiration, potentially allowing an attacker with a valid but expired token to continue accessing resources.

The vulnerability has a CVSS score of 5.0 (Medium), with a vector indicating network access, low attack complexity, low privileges required, and no user interaction. The impact is limited to low confidentiality and integrity breaches, with no availability impact. No public proof-of-concept (PoC) or exploit code has been identified, and the EPSS score is 0.0%, suggesting low exploitation activity in the wild.

⚡ AUTOMATE YOUR CVE INTELLIGENCE

This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.

›Patch confidence — UNVERIFIED to CONFIRMED, cross-referenced NVD + RHSA + Debian
›Exploit & PoC — poc_status, poc_url, has_exploit. Not in NVD.
›Shodan dorks — ready-made queries to find exposed vulnerable systems
›Detection rules — YARA · Wazuh · Elastic (all plans) · Sigma (Pro)
›pending_fields — know exactly which of 7 fields NVD hasn't processed yet
›Free backfill — data incomplete when you paid? Re-check within 30 days = 0 credits
PAYG €0.08/lookup Standard €19/mo (was €29) · 5k credits Pro €65/mo (was €99) · 20k credits FOUNDING PRICE · LOCKED FOR LIFE · ENDS 31 DEC 2026
[ FROM €19/MO ]
Free sandbox key available
No signup required

Supply Chain & Package Security

This vulnerability is not related to any specific package ecosystem (NPM, PyPI, Go, Ruby). It affects the Oxide control plane, which is a proprietary software component used in Oxide's infrastructure. No open-source patch data or GitHub advisory context is available.

CVSS Breakdown & Threat Level

  • CVSS Score: 5.0 (Medium)
  • Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
  • Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
  • Attack Complexity (AC): Low – No special conditions or mitigations are required.
  • Privileges Required (PR): Low – An attacker needs valid credentials (e.g., a valid API token) to exploit this.
  • User Interaction (UI): None – No user action is required.
  • Scope (S): Unchanged – The exploit cannot affect resources beyond the vulnerable component.
  • Confidentiality (C): Low – Limited information disclosure is possible.
  • Integrity (I): Low – Limited data modification is possible.
  • Availability (A): None – No impact on system availability.

Threat Level: Medium. The vulnerability requires prior access to a valid token, but once obtained, an attacker can extend access indefinitely, bypassing expiration controls.

Deep Dive & Mechanics

The Oxide control plane manages API tokens for authentication and authorization. Tokens are issued with an expiration date to limit their validity period. The vulnerability lies in the token renewal mechanism: when a token is renewed, the system fails to check if the original token has already expired. This allows an attacker to renew an expired token, effectively extending its lifetime beyond the intended expiration.

Root Cause: The renewal endpoint does not validate the current expiration status of the token before issuing a new one. The code likely checks the token's existence and validity (e.g., signature) but omits the expiration check.

Attack Scenario:

  1. An attacker obtains a valid API token (e.g., through credential theft, insider threat, or previous compromise).
  2. The token expires according to its original expiration date.
  3. The attacker sends a renewal request to the control plane's token renewal endpoint.
  4. The system accepts the request and issues a new token with an extended expiration date.
  5. The attacker can now continue using the API with the renewed token.

Impact: This undermines the security policy of token expiration, potentially allowing persistent unauthorized access. The low CVSS score reflects the need for prior token access, but in environments where tokens are shared or leaked, this can lead to prolonged compromise.

Vulnerable vs. Patched Code

Since no patch details are available, the following is a hypothetical comparison based on the vulnerability description.

Vulnerable Code (Pseudocode):

def renew_token(token_id, user):
    token = get_token_from_db(token_id)
    if token and token.user_id == user.id:
        new_token = create_new_token(user)
        return new_token
    else:
        return error("Invalid token")

Patched Code (Hypothetical):

def renew_token(token_id, user):
    token = get_token_from_db(token_id)
    if token and token.user_id == user.id and token.expires_at > datetime.utcnow():
        new_token = create_new_token(user)
        return new_token
    else:
        return error("Invalid or expired token")

The patched version adds a check for token.expires_at > datetime.utcnow() to ensure the token is not expired before renewal.

Exploitation & Lab Setup

Red Team

Objective: Demonstrate token renewal past expiration.

Prerequisites:

  • Access to a vulnerable Oxide control plane (version 15-17).
  • A valid API token (even if expired).

Steps:

  1. Obtain an expired token (e.g., from logs or previous session).
  2. Send a renewal request to the token renewal endpoint:
    curl -X POST https://oxide-control-plane/api/tokens/renew \
      -H "Authorization: Bearer <expired_token>" \
      -H "Content-Type: application/json"
    
  3. If successful, the response will contain a new token with an extended expiration date.
  4. Use the new token to access protected resources.

Expected Output:

{
  "token": "new_valid_token",
  "expires_at": "2026-01-01T00:00:00Z"
}

Blue Team

Detection:

  • Monitor for renewal requests on expired tokens.
  • Alert on tokens that are renewed multiple times or have unusually long lifetimes.
  • Implement logging of token renewal events with timestamps and user IDs.

Prevention:

  • Apply the patch (upgrade to version 17.1 or later).
  • Implement additional checks: validate token expiration before renewal.
  • Use short-lived tokens and enforce re-authentication for renewal.

Hunting:

  • Search logs for renewal requests where the original token's expiration date is in the past.
  • Correlate token creation and renewal timestamps to identify anomalies.

Indicators of Compromise (IOCs)

  • Network: Unusual renewal requests to /api/tokens/renew with expired tokens.
  • Logs: Token renewal events where original_expires_at is before the renewal timestamp.
  • Tokens: Tokens with expiration dates far beyond the standard policy (e.g., > 90 days).
  • User Behavior: Users renewing tokens multiple times without re-authentication.

Detection Engineering

YARA Rule

rule detect_expired_token_renewal {
    meta:
        description = "Detects renewal of expired API tokens in Oxide control plane logs"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2025-66432"
    strings:
        $renewal = "renew_token" nocase
        $expired = "expired" nocase
        $token = "token" nocase
    condition:
        all of them
}

Sigma Rule

title: Oxide Control Plane Expired Token Renewal
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects renewal of expired API tokens in Oxide control plane logs
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: oxide_control_plane
detection:
    selection:
        event: "token_renewal"
        original_expires_at|lt: "now"
    condition: selection
falsepositives:
    - Legitimate token renewal after re-authentication (if patched)
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-66432 - Oxide Control Plane Expired Token Renewal";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/api/tokens/renew"; http_uri;
    content:"Authorization"; http_header;
    pcre:"/Bearer\s+[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+\.[A-Za-z0-9-_]+/";
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

  1. Upgrade: Update the Oxide control plane to version 17.1 or later, where the vulnerability is fixed.
  2. Token Rotation: Revoke all existing tokens and issue new ones with proper expiration.
  3. Monitor: Review logs for any suspicious token renewal activity.

Long-term Measures:

  • Implement strict expiration checks in all token-related operations.
  • Use short-lived tokens (e.g., 1 hour) and require re-authentication for renewal.
  • Enable audit logging for all token lifecycle events.
  • Conduct regular security reviews of authentication mechanisms.

Workarounds (if patching is not possible):

  • Disable the token renewal endpoint if not required.
  • Implement a custom middleware to validate token expiration before renewal.
  • Use network segmentation to limit access to the control plane.

Report generated by Valters IT DevSecOps & CTI Framework

◈ SOURCE Analysis & enrichment: valtersit.com/cve/CVE-2025-66432/ · CVE data: NVD/MITRE (public domain) · © 2026 ValtersIT Hub
>_ SYSTEM_CORE: INTEL_ACTIVE
90% TEAM-CURATED // 10% AUTOMATED INGESTION.
ALL PATCH REFERENCES AND VERSION DATA SOURCED FROM NVD + OSV OFFICIAL REGISTRIES.