Common Weakness Enumeration

CWE-348

Allowed

Use of Less Trusted Source

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product has two different sources of the same data or information, but it uses the source that has less support for verification, is less trusted, or is less resistant to attack.

161 vulnerabilities reference this CWE, most recent first.

GHSA-8P2X-5CPM-QRQW

Vulnerability from github – Published: 2026-03-25 19:54 – Updated: 2026-03-25 19:54
VLAI
Summary
AVideo vulnerable to IP Address Spoofing via Untrusted HTTP Headers in getRealIpAddr()
Details

Summary

The getRealIpAddr() function in objects/functions.php trusts user-controlled HTTP headers to determine the client's IP address. An attacker can spoof their IP address by sending forged headers, bypassing any IP-based access controls or audit logging.

Vulnerable Code

File: objects/functions.php

$headers = [
    'HTTP_X_REAL_IP',      
    'HTTP_CLIENT_IP',    
    'HTTP_X_FORWARDED_FOR',
    'REMOTE_ADDR'
];

foreach ($headers as $header) {
    if (!empty($_SERVER[$header])) {
        $ips = explode(',', $_SERVER[$header]);
        foreach ($ips as $ipCandidate) {
            $ipCandidate = trim($ipCandidate);
            if (filter_var($ipCandidate, FILTER_VALIDATE_IP, 
                           FILTER_FLAG_IPV4)) {
                return $ipCandidate; 
            }
        }
    }
}

Attack Scenario

  1. Attacker sends request with forged header:
X-Client-IP: 127.0.0.1

or

X-Real-IP: 192.168.1.1
  1. getRealIpAddr() returns the forged IP
  2. Any IP-based rate limiting, access control, or audit log that relies on this function is bypassed

Proof of Concept

curl -H "X-Client-IP: 127.0.0.1" \
     https://target.com/any_endpoint.php

The server now believes the request came from localhost.

Impact

  • Bypass IP-based rate limiting
  • Bypass IP-based access controls
  • Forge audit log entries
  • Potential privilege escalation if localhost is trusted
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": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33690"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-25T19:54:42Z",
    "nvd_published_at": "2026-03-23T19:16:42Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe `getRealIpAddr()` function in `objects/functions.php` trusts user-controlled HTTP headers to determine the client\u0027s IP address. \nAn attacker can spoof their IP address by sending forged headers, bypassing any IP-based access controls or audit logging.\n\n## Vulnerable Code\n\nFile: `objects/functions.php`\n```php\n$headers = [\n    \u0027HTTP_X_REAL_IP\u0027,      \n    \u0027HTTP_CLIENT_IP\u0027,    \n    \u0027HTTP_X_FORWARDED_FOR\u0027,\n    \u0027REMOTE_ADDR\u0027\n];\n\nforeach ($headers as $header) {\n    if (!empty($_SERVER[$header])) {\n        $ips = explode(\u0027,\u0027, $_SERVER[$header]);\n        foreach ($ips as $ipCandidate) {\n            $ipCandidate = trim($ipCandidate);\n            if (filter_var($ipCandidate, FILTER_VALIDATE_IP, \n                           FILTER_FLAG_IPV4)) {\n                return $ipCandidate; \n            }\n        }\n    }\n}\n```\n\n## Attack Scenario\n\n1. Attacker sends request with forged header:\n```\nX-Client-IP: 127.0.0.1\n```\nor\n```\nX-Real-IP: 192.168.1.1\n```\n\n2. `getRealIpAddr()` returns the forged IP\n3. Any IP-based rate limiting, access control, or audit \n   log that relies on this function is bypassed\n\n## Proof of Concept\n```bash\ncurl -H \"X-Client-IP: 127.0.0.1\" \\\n     https://target.com/any_endpoint.php\n```\n\nThe server now believes the request came from localhost.\n\n## Impact\n- Bypass IP-based rate limiting\n- Bypass IP-based access controls\n- Forge audit log entries\n- Potential privilege escalation if localhost is trusted",
  "id": "GHSA-8p2x-5cpm-qrqw",
  "modified": "2026-03-25T19:54:42Z",
  "published": "2026-03-25T19:54:42Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-8p2x-5cpm-qrqw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33690"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/1a1df6a9377e5cc67d1d0ac8ef571f7abbffbc6c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "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": "AVideo vulnerable to IP Address Spoofing via Untrusted HTTP Headers in getRealIpAddr()"
}

GHSA-98GC-8MJ5-CC3R

Vulnerability from github – Published: 2023-09-05 03:30 – Updated: 2024-04-04 07:26
VLAI
Details

IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls. IBM X-Force ID: 259649.

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-2023-35906"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-291",
      "CWE-345",
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-09-05T01:15:07Z",
    "severity": "HIGH"
  },
  "details": "IBM Aspera Faspex 5.0.5 could allow a remote attacked to bypass IP restrictions due to improper access controls.  IBM X-Force ID:  259649.",
  "id": "GHSA-98gc-8mj5-cc3r",
  "modified": "2024-04-04T07:26:29Z",
  "published": "2023-09-05T03:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-35906"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/259649"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7029681"
    }
  ],
  "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-9P7X-652M-PW9Q

Vulnerability from github – Published: 2024-08-31 12:30 – Updated: 2024-08-31 12:30
VLAI
Details

The Web Application Firewall plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.1.2. This is due to insufficient restrictions on where the IP Address information is being retrieved for request logging and login restrictions. Attackers can supply the X-Forwarded-For header with with a different IP Address that will be logged and can be used to bypass settings that may have blocked out an IP address or country from logging in.

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-2022-4539"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345",
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-08-31T10:15:04Z",
    "severity": "MODERATE"
  },
  "details": "The Web Application Firewall plugin for WordPress is vulnerable to IP Address Spoofing in versions up to, and including, 2.1.2. This is due to insufficient restrictions on where the IP Address information is being retrieved for request logging and login restrictions. Attackers can supply the X-Forwarded-For header with with a different IP Address that will be logged and can be used to bypass settings that may have blocked out an IP address or country from logging in.",
  "id": "GHSA-9p7x-652m-pw9q",
  "modified": "2024-08-31T12:30:43Z",
  "published": "2024-08-31T12:30:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-4539"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3055548/web-application-firewall/trunk/helper/utility.php"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/0e99531c-8742-4f91-8525-65bb3cb06644?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-C6QP-PC37-G43R

Vulnerability from github – Published: 2025-05-23 09:30 – Updated: 2025-05-23 09:30
VLAI
Details

The optional feature 'Anti-Virus & Sandbox' of i-FILTER contains an issue with improper pattern file validation. If exploited, the product may treat an unauthorized pattern file as an authorized. If the product uses a specially crafted pattern file, information in the server where the product is running may be retrieved, and/or cause a denial of service (DoS) condition.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-47149"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-23T09:15:20Z",
    "severity": "MODERATE"
  },
  "details": "The optional feature \u0027Anti-Virus \u0026 Sandbox\u0027 of i-FILTER contains an issue with improper pattern file validation. If exploited, the product may treat an unauthorized pattern file as an authorized. If the product uses a specially crafted pattern file, information in the server where the product is running may be retrieved, and/or cause a denial of service (DoS) condition.",
  "id": "GHSA-c6qp-pc37-g43r",
  "modified": "2025-05-23T09:30:26Z",
  "published": "2025-05-23T09:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47149"
    },
    {
      "type": "WEB",
      "url": "https://download.daj.co.jp/support/detail/?page=releasenote_content\u0026division=6\u0026id=1057"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN68079883"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/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-C8W2-FGVX-VHV4

Vulnerability from github – Published: 2026-09-18 17:15 – Updated: 2026-09-18 17:15
VLAI
Summary
kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/warrants and impersonate system:masters in any workspace
Details

Summary

The kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own X-Remote-Group and X-Remote-Extra-* headers, which the shard trusts as a verified identity assertion — allowing a low-privilege user to escalate to cluster administrator (system:masters) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.

Impact

In a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (X-Remote-User / X-Remote-Group / X-Remote-Extra-*). The shard trusts these headers because they arrive over the front-proxy's mutually-authenticated connection.

Because the front-proxy appended its identity headers instead of replacing them — and never removed any copies the client sent — an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:

  • assert X-Remote-Group: system:masters and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;
  • forge authorization.kcp.io/warrant to assume an arbitrary user/group identity via kcp's delegated-identity mechanism;
  • forge authentication.kcp.io/scopes to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;
  • satisfy per-workspace required-group gating by injecting the required group.

The result is arbitrary read/write/delete access to any tenant's resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters — a cross-workspace access break and authorizer bypass across the proxy's trust boundary.

Patches

Fixed in v0.31.4, 0.32.2. The front-proxy and the shard's in-process local-proxy now unconditionally remove any inbound X-Remote-* identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.

Operators should upgrade to a patched release. No configuration changes are required after upgrading.

Workarounds

There is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping X-Remote-User, X-Remote-Group, and all X-Remote-Extra-* headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.

Credit to 5ud0er / Tarmo Technologies.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kcp-dev/kcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/kcp-dev/kcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.32.0"
            },
            {
              "fixed": "0.32.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61682"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-302",
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-18T17:15:49Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "# Summary\n\nThe kcp front-proxy fails to strip client-supplied identity headers before forwarding requests to shards. Any authenticated tenant can inject their own `X-Remote-Group` and `X-Remote-Extra-*` headers, which the shard trusts as a verified identity assertion \u2014 allowing a low-privilege user to escalate to cluster administrator (`system:masters`) and read, write, or delete resources in any workspace on the shard. This is a complete multi-tenant isolation and authorization bypass.\n\n## Impact \n\nIn a sharded kcp deployment, external clients reach shards through the front-proxy, which authenticates the client and then forwards the resulting identity to the shard using Kubernetes request-header authentication (`X-Remote-User` / `X-Remote-Group` / `X-Remote-Extra-*`). The shard trusts these headers because they arrive over the front-proxy\u0027s mutually-authenticated connection.\n\nBecause the front-proxy appended its identity headers instead of replacing them \u2014 and never removed any copies the client sent \u2014 an authenticated attacker could smuggle forged identity headers through to the shard. With this, an attacker holding any ordinary credential (client certificate, OIDC token, or service-account token) and no special privileges could:\n\n- assert `X-Remote-Group: system:masters` and act as cluster super-user, bypassing the entire kcp authorizer chain in every workspace on the shard;\n- forge `authorization.kcp.io/warrant` to assume an arbitrary user/group identity via kcp\u0027s delegated-identity mechanism;\n- forge `authentication.kcp.io/scopes` to escape the cluster-scoping that confines service-account and impersonated identities to their origin workspace;\n- satisfy per-workspace required-group gating by injecting the required group.\n\nThe result is arbitrary read/write/delete access to any tenant\u0027s resources, secrets, RBAC, APIExports/APIBindings, and LogicalClusters \u2014 a cross-workspace access break and authorizer bypass across the proxy\u0027s trust boundary.\n\n\n# Patches\nFixed in v0.31.4, 0.32.2. The front-proxy and the shard\u0027s in-process local-proxy now unconditionally remove any inbound `X-Remote-*` identity headers before stamping the authenticated identity, so no client-supplied value can be forwarded to a shard.\n\nOperators should upgrade to a patched release. No configuration changes are required after upgrading.\n\n# Workarounds\n\nThere is no complete workaround other than upgrading. Deployments that terminate client connections at an external proxy capable of stripping `X-Remote-User`, `X-Remote-Group`, and all `X-Remote-Extra-*` headers from inbound requests before they reach the kcp front-proxy can mitigate exposure in the interim.\n\nCredit to [5ud0er](https://github.com/5ud0er) / Tarmo Technologies.",
  "id": "GHSA-c8w2-fgvx-vhv4",
  "modified": "2026-09-18T17:15:49Z",
  "published": "2026-09-18T17:15:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/security/advisories/GHSA-c8w2-fgvx-vhv4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/commit/7437cdcfec8f927d1a9bf1b2dd1e075d038e27ca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kcp-dev/kcp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/releases/tag/v0.31.4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kcp-dev/kcp/releases/tag/v0.32.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kcp front-proxy does not strip inbound X-Remote-* identity headers, allowing any authenticated client to inject groups/warrants and impersonate system:masters in any workspace"
}

GHSA-CH8C-P797-5CCG

Vulnerability from github – Published: 2026-07-03 15:31 – Updated: 2026-07-03 15:31
VLAI
Details

Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 contain an use of less trusted source vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to information tampering.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-46466"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-03T14:16:30Z",
    "severity": "LOW"
  },
  "details": "Dell PowerProtect Data Domain, versions 7.7.1.0 through 8.7, LTS2026 release version 8.6.1.0 through 8.6.1.10, LTS2025 release version 8.3.1.0 through 8.3.1.30, LTS2024 release versions 7.13.1.0 through 7.13.1.70 contain an use of less trusted source vulnerability. A high privileged attacker with remote access could potentially exploit this vulnerability, leading to information tampering.",
  "id": "GHSA-ch8c-p797-5ccg",
  "modified": "2026-07-03T15:31:58Z",
  "published": "2026-07-03T15:31:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46466"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000481268/dsa-2026-278-security-update-for-dell-powerprotect-data-domain-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-CRM4-Q7V4-C2R2

Vulnerability from github – Published: 2026-06-22 18:34 – Updated: 2026-09-21 22:27
VLAI
Summary
Canonical ADSys Uses a Less Trusted Source
Details

An issue was discovered in Canonical ADSys upstream versions through v0.16.2. During Active Directory Certificate Services (AD CS) certificate auto-enrollment via the vendored Samba client script (internal/policies/certificate/python/vendor_samba/gp/gp_cert_auto_enroll_ext.py), ADSys utilizes a plaintext HTTP connection (http://) instead of a secure HTTPS connection (https://) to request the CA certificate from the Active Directory Certificate Services server (GetCACert). An unauthenticated network attacker positioned between the managed Ubuntu host and the configured AD CS CA hostname can conduct a Man-in-the-Middle (MITM) attack. By intercepting the plaintext HTTP request, the attacker can supply an arbitrary, attacker-controlled Root CA certificate. Because the system automatically accepts this certificate and registers it into the local system trust store via update-ca-certificates, this results in system-wide trust store poisoning. Consequently, TLS clients utilizing the operating system trust store on the affected machine will accept rogue certificates for arbitrary domains, enabling persistent decryption and interception of subsequent TLS connections. This issue is resolved in version v0.16.3.

Severity
9.0 (Critical)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
9.0 (Critical)
CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/S:N/AU:Y/R:I/V:D/RE:L/U:Red
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/ubuntu/adsys"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.16.3-0.20250318112551-8b1939f96d38"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-12249"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-21T22:27:09Z",
    "nvd_published_at": "2026-06-22T18:16:31Z",
    "severity": "CRITICAL"
  },
  "details": "An issue was discovered in Canonical ADSys upstream versions through v0.16.2. During Active Directory Certificate Services (AD CS) certificate auto-enrollment via the vendored Samba client script (internal/policies/certificate/python/vendor_samba/gp/gp_cert_auto_enroll_ext.py), ADSys utilizes a plaintext HTTP connection (http://) instead of a secure HTTPS connection (https://) to request the CA certificate from the Active Directory Certificate Services server (GetCACert). An unauthenticated network attacker positioned between the managed Ubuntu host and the configured AD CS CA hostname can conduct a Man-in-the-Middle (MITM) attack. By intercepting the plaintext HTTP request, the attacker can supply an arbitrary, attacker-controlled Root CA certificate. Because the system automatically accepts this certificate and registers it into the local system trust store via update-ca-certificates, this results in system-wide trust store poisoning. Consequently, TLS clients utilizing the operating system trust store on the affected machine will accept rogue certificates for arbitrary domains, enabling persistent decryption and interception of subsequent TLS connections. This issue is resolved in version v0.16.3.",
  "id": "GHSA-crm4-q7v4-c2r2",
  "modified": "2026-09-21T22:27:09Z",
  "published": "2026-06-22T18:34:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12249"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ubuntu/adsys/commit/8b1939f96d3827b4426eb06c1ced5bf317b0a99d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ubuntu/adsys"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ubuntu/adsys/releases/tag/v0.16.3"
    },
    {
      "type": "WEB",
      "url": "https://ubuntu.com/security/CVE-2026-12249"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:P/S:N/AU:Y/R:I/V:D/RE:L/U:Red",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Canonical ADSys Uses a Less Trusted Source"
}

GHSA-FQ95-V8XC-JM3V

Vulnerability from github – Published: 2026-09-22 20:34 – Updated: 2026-09-22 20:34
VLAI
Summary
Fabio - Incomplete fix for CVE-2025-48865: operator-configured trust headers (clientip/tls/requestid) still strippable via the Connection header
Details

Affected: github.com/fabiolb/fabio >= 1.6.6 through 1.7.1 and master HEAD (c75f8a6).

Summary

The v1.6.6 fix for CVE-2025-48865 sweeps the client Connection header against a hardcoded allowlist protectHeaders (proxy/http_headers.go:28-36) containing only the 7 X-Forwarded family headers. Fabio also injects three operator-configured server-side trust headers that are NOT in that allowlist, so the original hop-by-hop stripping attack still works against them.

Details

The three unprotected trust headers and where fabio sets them: - ClientIPHeader (proxy.header.clientip) - http_headers.go:73 r.Header.Set(cfg.ClientIPHeader, remoteIP) - TLSHeader (proxy.header.tls) - http_headers.go:153 r.Header.Set(cfg.TLSHeader, cfg.TLSHeaderValue) (TLS connections) - RequestID (proxy.header.requestid) - http_proxy.go:90 r.Header.Set(p.Config.RequestID, id())

Order of operations in HTTPProxy.ServeHTTP: (1) line 90 sets RequestID; (2) line 175 calls addHeaders, which sweeps the Connection header (keeping the three configured names because they are absent from protectHeaders) and then sets ClientIPHeader/TLSHeader; (3) line 223 runs the Go httputil.ReverseProxy, whose removeHopByHopHeaders (Go stdlib net/http/httputil/reverseproxy.go) iterates the inbound Connection header and h.Dels every listed header. The three trust headers fabio just set are therefore deleted before the request reaches the backend.

PoC

Configure proxy.header.clientip=X-Client-IP, proxy.header.requestid=X-Request-ID. Raw request:

GET / HTTP/1.1
Host: foo.com
Connection: close, X-Client-IP, X-Request-ID

Backend sees X-Client-IP: <empty> and X-Request-ID: <empty>. Baseline (Connection: close) => backend sees the real client IP and a request id. The same works for proxy.header.tls over TLS (Connection: close, X-Secure strips the TLS assertion). Reproduced by the two PASS-ing tests in proxy/poc_cve48865_incomplete_test.go on master HEAD (Go 1.26.4). Control: X-Forwarded-For (in protectHeaders) survives, confirming the gap is specific to the configured headers.

Impact

Where a backend trusts these fabio-set headers, an external unauthenticated client can strip/downgrade the trust signal: bypass/poison IP-based ACL or audit that reads the clientip header, downgrade a TLS-terminated request to appear non-TLS to a backend keying off the TLS header, or drop request-id correlation. Scope: deployments that enable the relevant proxy.header.* option (all empty by default). Fix: add the configured ClientIPHeader/TLSHeader/RequestID names to the protectHeaders set (or strip their token from the inbound Connection header) inside addHeaders.

Parent: CVE-2025-48865 / GHSA-q7p4-7xjv-j3wf (fixed in v1.6.6). This is an incomplete-fix sibling - the same hop-by-hop stripping primitive applies to the operator-configured trust headers the allowlist does not cover.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/fabiolb/fabio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.6"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62987"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-348"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-22T20:34:22Z",
    "nvd_published_at": "2026-09-21T17:17:38Z",
    "severity": "MODERATE"
  },
  "details": "**Affected:** github.com/fabiolb/fabio \u003e= 1.6.6 through 1.7.1 and master HEAD (c75f8a6).\n\n### Summary\nThe v1.6.6 fix for CVE-2025-48865 sweeps the client `Connection` header against a hardcoded allowlist `protectHeaders` (proxy/http_headers.go:28-36) containing only the 7 X-Forwarded family headers. Fabio also injects three *operator-configured* server-side trust headers that are NOT in that allowlist, so the original hop-by-hop stripping attack still works against them.\n\n### Details\nThe three unprotected trust headers and where fabio sets them:\n- ClientIPHeader (`proxy.header.clientip`) - http_headers.go:73 `r.Header.Set(cfg.ClientIPHeader, remoteIP)`\n- TLSHeader (`proxy.header.tls`) - http_headers.go:153 `r.Header.Set(cfg.TLSHeader, cfg.TLSHeaderValue)` (TLS connections)\n- RequestID (`proxy.header.requestid`) - http_proxy.go:90 `r.Header.Set(p.Config.RequestID, id())`\n\nOrder of operations in HTTPProxy.ServeHTTP: (1) line 90 sets RequestID; (2) line 175 calls addHeaders, which sweeps the Connection header (keeping the three configured names because they are absent from protectHeaders) and then sets ClientIPHeader/TLSHeader; (3) line 223 runs the Go `httputil.ReverseProxy`, whose `removeHopByHopHeaders` (Go stdlib net/http/httputil/reverseproxy.go) iterates the inbound `Connection` header and `h.Del`s every listed header. The three trust headers fabio just set are therefore deleted before the request reaches the backend.\n\n### PoC\nConfigure `proxy.header.clientip=X-Client-IP`, `proxy.header.requestid=X-Request-ID`. Raw request:\n```\nGET / HTTP/1.1\nHost: foo.com\nConnection: close, X-Client-IP, X-Request-ID\n```\nBackend sees `X-Client-IP: \u003cempty\u003e` and `X-Request-ID: \u003cempty\u003e`. Baseline (`Connection: close`) =\u003e backend sees the real client IP and a request id. The same works for `proxy.header.tls` over TLS (`Connection: close, X-Secure` strips the TLS assertion). Reproduced by the two PASS-ing tests in proxy/poc_cve48865_incomplete_test.go on master HEAD (Go 1.26.4). Control: `X-Forwarded-For` (in protectHeaders) survives, confirming the gap is specific to the configured headers.\n\n### Impact\nWhere a backend trusts these fabio-set headers, an external unauthenticated client can strip/downgrade the trust signal: bypass/poison IP-based ACL or audit that reads the clientip header, downgrade a TLS-terminated request to appear non-TLS to a backend keying off the TLS header, or drop request-id correlation. Scope: deployments that enable the relevant `proxy.header.*` option (all empty by default). Fix: add the configured ClientIPHeader/TLSHeader/RequestID names to the protectHeaders set (or strip their token from the inbound Connection header) inside addHeaders.\n\nParent: CVE-2025-48865 / GHSA-q7p4-7xjv-j3wf (fixed in v1.6.6). This is an incomplete-fix sibling - the same hop-by-hop stripping primitive applies to the operator-configured trust headers the allowlist does not cover.",
  "id": "GHSA-fq95-v8xc-jm3v",
  "modified": "2026-09-22T20:34:22Z",
  "published": "2026-09-22T20:34:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fabiolb/fabio/security/advisories/GHSA-fq95-v8xc-jm3v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62987"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fabiolb/fabio/commit/240526a8004077edad4fb96d25b382bfc3901357"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fabiolb/fabio"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fabiolb/fabio/releases/tag/v1.7.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fabio - Incomplete fix for CVE-2025-48865: operator-configured trust headers (clientip/tls/requestid) still strippable via the Connection header"
}

GHSA-FRGP-CM59-PW23

Vulnerability from github – Published: 2026-09-29 00:31 – Updated: 2026-09-29 00:31
VLAI
Details

A security flaw has been discovered in Trusted Domain Project OpenDKIM up to 2.11.0. The impacted element is the function dkim_process_set of the file dkim.c of the component Tag Tokenizer. Performing a manipulation results in use of less trusted source. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-101277"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-29T00:17:03Z",
    "severity": "MODERATE"
  },
  "details": "A security flaw has been discovered in Trusted Domain Project OpenDKIM up to 2.11.0. The impacted element is the function dkim_process_set of the file dkim.c of the component Tag Tokenizer. Performing a manipulation results in use of less trusted source. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-frgp-cm59-pw23",
  "modified": "2026-09-29T00:31:39Z",
  "published": "2026-09-29T00:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-101277"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-101277"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/918270"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/411034"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/411034/cti"
    },
    {
      "type": "WEB",
      "url": "https://xuyongzhe-vt.github.io/share/opendkim-tag-parser-desync.html"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-FXXQ-29XM-F392

Vulnerability from github – Published: 2026-09-23 21:30 – Updated: 2026-09-24 09:31
VLAI
Details

A flaw was found in the Ansible Automation Platform automation-controller. In the shipped production configuration, the Controller trusts the client-supplied X-Forwarded-For header as the request's client IP without verifying that it originated from a trusted proxy, and selects the leftmost (attacker-controlled) header value. As a result, an attacker can forge the source IP address recorded for their requests in the Controller's audit and access logs, degrading the integrity of forensic and SIEM attribution. The flaw does not grant additional access.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-84718"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-348"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-23T20:17:18Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in the Ansible Automation Platform automation-controller. In the shipped\nproduction configuration, the Controller trusts the client-supplied X-Forwarded-For header as\nthe request\u0027s client IP without verifying that it originated from a trusted proxy, and selects\nthe leftmost (attacker-controlled) header value. As a result, an attacker can forge the source\nIP address recorded for their requests in the Controller\u0027s audit and access logs, degrading\nthe integrity of forensic and SIEM attribution. The flaw does not grant additional access.",
  "id": "GHSA-fxxq-29xm-f392",
  "modified": "2026-09-24T09:31:50Z",
  "published": "2026-09-23T21:30:58Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84718"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71113"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71114"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71177"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:71179"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-84718"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2527211"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/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-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-76: Manipulating Web Input to File System Calls

An attacker manipulates inputs to the target software which the target software passes to file system calls in the OS. The goal is to gain access to, and perhaps modify, areas of the file system that the target software did not intend to be accessible.

CAPEC-85: AJAX Footprinting

This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.

← Back to the CWE list