GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-807

Allowed

Reliance on Untrusted Inputs in a Security Decision

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product uses a protection mechanism that relies on the existence or values of an input, but the input can be modified by an untrusted actor in a way that bypasses the protection mechanism.

175 vulnerabilities reference this CWE, most recent first.

GHSA-J88C-7M8J-3G32

Vulnerability from github – Published: 2026-01-13 18:31 – Updated: 2026-01-13 18:31
VLAI
Details

Reliance on untrusted inputs in a security decision in Windows Kerberos allows an authorized attacker to elevate privileges over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-20849"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-13T18:16:13Z",
    "severity": "HIGH"
  },
  "details": "Reliance on untrusted inputs in a security decision in Windows Kerberos allows an authorized attacker to elevate privileges over a network.",
  "id": "GHSA-j88c-7m8j-3g32",
  "modified": "2026-01-13T18:31:09Z",
  "published": "2026-01-13T18:31:09Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-20849"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-20849"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-J9GF-VW2F-9HRW

Vulnerability from github – Published: 2026-06-12 18:28 – Updated: 2026-06-12 18:28
VLAI
Summary
Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation
Details

Summary

A configuration-dependent origin validation bypass was identified in Appsmith’s password reset and email verification flows on current release.

Both flows derive the email-link base URL from the request Origin header. The current validation only enforces a trusted base URL when APPSMITH_BASE_URL is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.

On deployments with email delivery enabled and APPSMITH_BASE_URL unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.

Details

The current release head at commit e77639eca4974469c1e676904851ffdaedd38111 was reviewed.

The relevant routes are publicly reachable in SecurityConfig.java:

  • POST /forgotPassword is permitted without authentication at line 209
  • POST /resendEmailVerification is permitted without authentication at line 228

In UserControllerCE.java, both flows copy the request Origin header into the DTO field used as the email-link base URL:

  • forgotPasswordRequest(...) at lines 91-94
  • resendEmailVerification(...) at lines 189-193

In UserServiceCEImpl.java, base URL validation is conditional:

  • @Value("${APPSMITH_BASE_URL:}") at line 113
  • resolveSecureBaseUrl(...) at lines 132-145

That method explicitly documents and implements this behavior:

  • if APPSMITH_BASE_URL is configured, the provided URL must match it
  • if APPSMITH_BASE_URL is unset, the provided URL is accepted for backward compatibility

The resulting base URL is then used to construct token-bearing links:

  • FORGOT_PASSWORD_CLIENT_URL_FORMAT at line 149
  • reset URL generation at lines 282-289
  • EMAIL_VERIFICATION_CLIENT_URL_FORMAT at line 152
  • verification URL generation at lines 931-940

This means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.

Note that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:

  • app/client/src/ce/pages/AdminSettings/config/configuration.tsx at lines 41-49

The reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set APPSMITH_BASE_URL.

PoC

These steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.

  1. Deploy a non-production Appsmith instance from current release, or any build containing the affected code.
  2. Enable outbound email delivery.
  3. Leave APPSMITH_BASE_URL unset or blank.
  4. Use a test mailbox account you control, for example victim@example.test.
  5. Send a password reset request with a forged Origin header:
curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/forgotPassword' \
  -H 'Content-Type: application/json' \
  -H 'Origin: https://attacker.example' \
  --data '{"email":"victim@example.test"}'
  1. Inspect the delivered email. If affected, the clickable reset link is generated under https://attacker.example/... instead of the legitimate Appsmith host.
  2. Repeat the same validation for resend email verification using an unverified test account:
curl -i -X POST 'https://YOUR-INSTANCE/api/v1/users/resendEmailVerification' \
  -H 'Content-Type: application/json' \
  -H 'Origin: https://attacker.example' \
  --data '{"email":"victim@example.test"}'
  1. Inspect the delivered verification email. If affected, the clickable verification link is generated under https://attacker.example/....
  2. Set APPSMITH_BASE_URL=https://YOUR-INSTANCE, restart the server, and repeat the same requests.
  3. The expected secure behavior is that mismatched Origin is rejected, or the generated links no longer follow the forged request header.

Live tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.

Impact

This is a trust-boundary failure in token-bearing email authentication flows.

Affected deployments are those where:

  • APPSMITH_BASE_URL is unset or blank
  • outbound email is enabled
  • password reset and/or email verification flows are enabled

Attacker requirements are low:

  • no prior authentication is required to reach the relevant endpoints
  • the attacker only needs to trigger an email flow toward a target account

Security impact:

  • Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled
  • victim interaction can expose security-sensitive token material
  • this can plausibly result in account takeover
  • at minimum, it enables trusted-email abuse and phishing through the application itself

mitigation

  1. Remove the fallback behavior in resolveSecureBaseUrl(...) that accepts caller-supplied origin data when APPSMITH_BASE_URL is unset.
  2. Fail closed for all token-bearing email flows when no trusted base URL is configured.
  3. Use a single trusted-base-url helper across:
  4. password reset
  5. resend email verification
  6. invite flows
  7. instance admin invite flows
  8. Add regression tests for the unset-configuration case.
  9. Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.

Attachment

appsmith-email-link-origin-validation-bypass-20260321.zip

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.appsmith:server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-12T18:28:52Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nA configuration-dependent origin validation bypass was identified in Appsmith\u2019s password reset and email verification flows on current `release`.\n\nBoth flows derive the email-link base URL from the request `Origin` header. The current validation only enforces a trusted base URL when `APPSMITH_BASE_URL` is configured. If that setting is unset, the application accepts the caller-supplied origin and uses it to generate token-bearing reset and verification links.\n\nOn deployments with email delivery enabled and `APPSMITH_BASE_URL` unset, this can cause Appsmith to send security-sensitive links whose clickable host is attacker-controlled, which can plausibly lead to account takeover after victim interaction.\n\n### Details\nThe current `release` head at commit `e77639eca4974469c1e676904851ffdaedd38111` was reviewed.\n\nThe relevant routes are publicly reachable in `SecurityConfig.java`:\n\n- `POST /forgotPassword` is permitted without authentication at line `209`\n- `POST /resendEmailVerification` is permitted without authentication at line `228`\n\nIn `UserControllerCE.java`, both flows copy the request `Origin` header into the DTO field used as the email-link base URL:\n\n- `forgotPasswordRequest(...)` at lines `91-94`\n- `resendEmailVerification(...)` at lines `189-193`\n\nIn `UserServiceCEImpl.java`, base URL validation is conditional:\n\n- `@Value(\"${APPSMITH_BASE_URL:}\")` at line `113`\n- `resolveSecureBaseUrl(...)` at lines `132-145`\n\nThat method explicitly documents and implements this behavior:\n\n- if `APPSMITH_BASE_URL` is configured, the provided URL must match it\n- if `APPSMITH_BASE_URL` is unset, the provided URL is accepted for backward compatibility\n\nThe resulting base URL is then used to construct token-bearing links:\n\n- `FORGOT_PASSWORD_CLIENT_URL_FORMAT` at line `149`\n- reset URL generation at lines `282-289`\n- `EMAIL_VERIFICATION_CLIENT_URL_FORMAT` at line `152`\n- verification URL generation at lines `931-940`\n\nThis means the base URL is not only used for branding or display purposes. It directly controls the clickable host of security-sensitive reset and verification links.\n\nNote that the admin UI describes APPSMITH_BASE_URL as required for password reset and email verification links in:\n\n- `app/client/src/ce/pages/AdminSettings/config/configuration.tsx` at lines `41-49`\n\nThe reviewed self-host material indicates this protection is not fail-closed by default, which makes the vulnerable condition realistic on existing deployments where operators have not set `APPSMITH_BASE_URL`.\n\n\n### PoC\nThese steps were designed for validation on an Appsmith deployment that I own or am explicitly authorized to test.\n\n1. Deploy a non-production Appsmith instance from current `release`, or any build containing the affected code.\n2. Enable outbound email delivery.\n3. Leave `APPSMITH_BASE_URL` unset or blank.\n4. Use a test mailbox account you control, for example `victim@example.test`.\n5. Send a password reset request with a forged `Origin` header:\n\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/forgotPassword\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Origin: https://attacker.example\u0027 \\\n  --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n6. Inspect the delivered email. If affected, the clickable reset link is generated under `https://attacker.example/...` instead of the legitimate Appsmith host.\n7. Repeat the same validation for resend email verification using an unverified test account:\n```bash\ncurl -i -X POST \u0027https://YOUR-INSTANCE/api/v1/users/resendEmailVerification\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -H \u0027Origin: https://attacker.example\u0027 \\\n  --data \u0027{\"email\":\"victim@example.test\"}\u0027\n```\n\n8. Inspect the delivered verification email. If affected, the clickable verification link is generated under `https://attacker.example/....`\n9. Set `APPSMITH_BASE_URL=https://YOUR-INSTANCE`, restart the server, and repeat the same requests.\n10. The expected secure behavior is that mismatched `Origin`  is rejected, or the generated links no longer follow the forged request header.\n\nLive tokens, third-party data, or unsafe exploitation material was not included in this report. The attached archive contains source excerpts, data-flow proof, safe validation notes, and supporting evidence collected from the reviewed current branch.\n\n### Impact\nThis is a trust-boundary failure in token-bearing email authentication flows.\n\nAffected deployments are those where:\n\n- `APPSMITH_BASE_URL` is unset or blank\n- outbound email is enabled\n- password reset and/or email verification flows are enabled\n\nAttacker requirements are low:\n\n- no prior authentication is required to reach the relevant endpoints\n- the attacker only needs to trigger an email flow toward a target account\n\nSecurity impact:\n\n- Appsmith can generate password reset or verification emails whose clickable host is attacker-controlled\n- victim interaction can expose security-sensitive token material\n- this can plausibly result in account takeover\n- at minimum, it enables trusted-email abuse and phishing through the application itself\n \n### mitigation\n1. Remove the fallback behavior in `resolveSecureBaseUrl(...)` that accepts caller-supplied origin data when `APPSMITH_BASE_URL` is unset.\n2. Fail closed for all token-bearing email flows when no trusted base URL is configured.\n3. Use a single trusted-base-url helper across:\n   - password reset\n   - resend email verification\n   - invite flows\n   - instance admin invite flows\n4. Add regression tests for the unset-configuration case.\n5. Add startup or admin-level validation so security-sensitive email flows cannot operate until a trusted base URL is configured.\n\n### Attachment\n[appsmith-email-link-origin-validation-bypass-20260321.zip](https://github.com/user-attachments/files/26153718/appsmith-email-link-origin-validation-bypass-20260321.zip)",
  "id": "GHSA-j9gf-vw2f-9hrw",
  "modified": "2026-06-12T18:28:52Z",
  "published": "2026-06-12T18:28:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/security/advisories/GHSA-j9gf-vw2f-9hrw"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/appsmithorg/appsmith"
    },
    {
      "type": "WEB",
      "url": "https://github.com/appsmithorg/appsmith/releases/tag/v2.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Appsmith: Configuration-dependent origin validation bypass in password reset and email verification link generation"
}

GHSA-JGV3-53VR-XCFF

Vulnerability from github – Published: 2025-01-19 03:30 – Updated: 2025-01-19 03:30
VLAI
Details

IBM Security ReaQta 3.12 could allow an authenticated user to perform unauthorized actions due to reliance on untrusted inputs.

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-2024-45654"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-01-19T03:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM Security ReaQta 3.12 could allow an authenticated user to perform unauthorized actions due to reliance on untrusted inputs.",
  "id": "GHSA-jgv3-53vr-xcff",
  "modified": "2025-01-19T03:30:33Z",
  "published": "2025-01-19T03:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45654"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7175072"
    }
  ],
  "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"
    }
  ]
}

GHSA-JH49-RH44-24PQ

Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-04-24 00:31
VLAI
Details

A vulnerability in the browser-based remote management interface may allow an administrator to access sensitive information on the device via crafted requests, affecting certain production printers and office/small office multifunction printers.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-1789"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-24T00:16:26Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the browser-based remote management interface may allow an administrator to access sensitive information on the device via crafted requests, affecting certain production printers and office/small office multifunction printers.",
  "id": "GHSA-jh49-rh44-24pq",
  "modified": "2026-04-24T00:31:52Z",
  "published": "2026-04-24T00:31:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1789"
    },
    {
      "type": "WEB",
      "url": "https://canon.jp/support/support-info/260423vulnerability-response"
    },
    {
      "type": "WEB",
      "url": "https://psirt.canon/advisory-information/cp2026-003"
    },
    {
      "type": "WEB",
      "url": "https://www.canon-europe.com/support/product-security"
    },
    {
      "type": "WEB",
      "url": "https://www.usa.canon.com/about-us/to-our-customers/cpa2026-003-vulnerability-mitigation-remediation-for-production-printers-and-office-multifunction-printers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:N/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-JMHG-9C54-P575

Vulnerability from github – Published: 2026-07-17 18:31 – Updated: 2026-07-17 18:31
VLAI
Details

Keycloak provides a mechanism called Client Policies to enforce security requirements on clients, such as requiring them to use signed JWTs for authentication. A flaw was discovered where this enforcement can be bypassed. An attacker with valid client credentials can provide a fake, unsigned assertion header that tricks the system into thinking the policy requirements have been met. This allows the attacker to authenticate using simpler methods like a client secret even when the administrator has mandated more secure, signed assertions.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-16093"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-17T17:17:14Z",
    "severity": "MODERATE"
  },
  "details": "Keycloak provides a mechanism called Client Policies to enforce security requirements on clients, such as requiring them to use signed JWTs for authentication. A flaw was discovered where this enforcement can be bypassed. An attacker with valid client credentials can provide a fake, unsigned assertion header that tricks the system into thinking the policy requirements have been met. This allows the attacker to authenticate using simpler methods like a client secret even when the administrator has mandated more secure, signed assertions.",
  "id": "GHSA-jmhg-9c54-p575",
  "modified": "2026-07-17T18:31:26Z",
  "published": "2026-07-17T18:31:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16093"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-16093"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2501729"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-JP65-2H7Q-QFG7

Vulnerability from github – Published: 2025-07-23 12:30 – Updated: 2025-07-31 12:30
VLAI
Details

A Reliance on Untrusted Inputs in a Security Decision vulnerability in the logrotate configuration for openSUSEs mailman3 package allows potential escalation from mailman to rootThis issue affects openSUSE Tumbleweed: from ? before 3.3.10-2.1.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-53882"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-273",
      "CWE-807"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-07-23T10:15:24Z",
    "severity": "CRITICAL"
  },
  "details": "A Reliance on Untrusted Inputs in a Security Decision vulnerability in the logrotate configuration for openSUSEs mailman3 package allows\u00a0potential escalation from mailman to rootThis issue affects openSUSE Tumbleweed: from ? before 3.3.10-2.1.",
  "id": "GHSA-jp65-2h7q-qfg7",
  "modified": "2025-07-31T12:30:26Z",
  "published": "2025-07-23T12:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53882"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2025-53882"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/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-JQPQ-MGVM-F9R6

Vulnerability from github – Published: 2026-02-18 00:55 – Updated: 2026-03-06 01:04
VLAI
Summary
OpenClaw: Command hijacking via unsafe PATH handling (bootstrapping + node-host PATH overrides)
Details

Command hijacking via PATH handling

Discovered: 2026-02-04 Reporter: @akhmittra

Summary

OpenClaw previously accepted untrusted PATH sources in limited situations. In affected versions, this could cause OpenClaw to resolve and execute an unintended binary ("command hijacking") when running host commands.

This issue primarily matters when OpenClaw is relying on allowlist/safe-bin protections and expects PATH to be trustworthy.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: < 2026.2.14
  • Patched: >= 2026.2.14 (planned next release)

What Is Required To Trigger This

A) Node Host PATH override (remote command hijack)

An attacker needs all of the following:

  • Authenticated/authorized access to an execution surface that can invoke node-host execution (for example, a compromised gateway or a caller that can issue system.run).
  • A node host connected and exposing system.run.
  • A configuration where allowlist/safe-bins are expected to restrict execution (this is not meaningful if full arbitrary exec is already allowed).
  • The ability to pass request-scoped environment overrides (specifically PATH) into system.run.
  • A way to place an attacker-controlled executable earlier in PATH (for example, a writable directory on the node host), with a name that matches an allowlisted/safe-bin command that OpenClaw will run.

Notes:

  • OpenClaw deployments commonly require a gateway token/password (or equivalent transport authentication). This should not be treated as unauthenticated Internet RCE.
  • This scenario typically depends on non-standard / misconfigured deployments (for example, granting untrusted parties access to invoke node-host execution or otherwise exposing a privileged execution surface beyond the intended trust boundary).

B) Project-local PATH bootstrapping (local command hijack)

An attacker needs all of the following:

  • The victim runs OpenClaw from within an attacker-controlled working directory (for example, cloning and running inside a malicious repository).
  • That directory contains a node_modules/.bin/openclaw and additional attacker-controlled executables in the same directory.
  • OpenClaw subsequently executes a command by name (resolved via PATH) that matches one of those attacker-controlled executables.

Fix

  • Project-local node_modules/.bin PATH bootstrapping is now disabled by default. If explicitly enabled, it is append-only (never prepended) via OPENCLAW_ALLOW_PROJECT_LOCAL_BIN=1.
  • Node Host now ignores request-scoped PATH overrides.

Fix Commit(s)

  • 013e8f6b3be3333a229a066eef26a45fec47ffcc

Thanks @akhmittra for reporting.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29610"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-427",
      "CWE-78",
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T00:55:50Z",
    "nvd_published_at": "2026-03-05T22:16:24Z",
    "severity": "HIGH"
  },
  "details": "# Command hijacking via PATH handling\n\n**Discovered:** 2026-02-04\n**Reporter:** @akhmittra\n\n## Summary\n\nOpenClaw previously accepted untrusted PATH sources in limited situations. In affected versions, this could cause OpenClaw to resolve and execute an unintended binary (\"command hijacking\") when running host commands.\n\nThis issue primarily matters when OpenClaw is relying on allowlist/safe-bin protections and expects `PATH` to be trustworthy.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected: `\u003c 2026.2.14`\n- Patched: `\u003e= 2026.2.14` (planned next release)\n\n## What Is Required To Trigger This\n\n### A) Node Host PATH override (remote command hijack)\n\nAn attacker needs all of the following:\n\n- Authenticated/authorized access to an execution surface that can invoke node-host execution (for example, a compromised gateway or a caller that can issue `system.run`).\n- A node host connected and exposing `system.run`.\n- A configuration where allowlist/safe-bins are expected to restrict execution (this is not meaningful if full arbitrary exec is already allowed).\n- The ability to pass request-scoped environment overrides (specifically `PATH`) into `system.run`.\n- A way to place an attacker-controlled executable earlier in `PATH` (for example, a writable directory on the node host), with a name that matches an allowlisted/safe-bin command that OpenClaw will run.\n\nNotes:\n\n- OpenClaw deployments commonly require a gateway token/password (or equivalent transport authentication). This should not be treated as unauthenticated Internet RCE.\n- This scenario typically depends on **non-standard / misconfigured deployments** (for example, granting untrusted parties access to invoke node-host execution or otherwise exposing a privileged execution surface beyond the intended trust boundary).\n\n### B) Project-local PATH bootstrapping (local command hijack)\n\nAn attacker needs all of the following:\n\n- The victim runs OpenClaw from within an attacker-controlled working directory (for example, cloning and running inside a malicious repository).\n- That directory contains a `node_modules/.bin/openclaw` and additional attacker-controlled executables in the same directory.\n- OpenClaw subsequently executes a command by name (resolved via `PATH`) that matches one of those attacker-controlled executables.\n\n## Fix\n\n- Project-local `node_modules/.bin` PATH bootstrapping is now **disabled by default**. If explicitly enabled, it is **append-only** (never prepended) via `OPENCLAW_ALLOW_PROJECT_LOCAL_BIN=1`.\n- Node Host now ignores request-scoped `PATH` overrides.\n\n## Fix Commit(s)\n\n- 013e8f6b3be3333a229a066eef26a45fec47ffcc\n\nThanks @akhmittra for reporting.",
  "id": "GHSA-jqpq-mgvm-f9r6",
  "modified": "2026-03-06T01:04:18Z",
  "published": "2026-02-18T00:55:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-jqpq-mgvm-f9r6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29610"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/013e8f6b3be3333a229a066eef26a45fec47ffcc"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.14"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-command-hijacking-via-unsafe-path-handling"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Command hijacking via unsafe PATH handling (bootstrapping + node-host PATH overrides)"
}

GHSA-M547-HP4W-J6JX

Vulnerability from github – Published: 2026-03-20 14:41 – Updated: 2026-03-20 21:28
VLAI
Summary
Vikunja has a Rate-Limit Bypass for Unauthenticated Users via Spoofed Headers
Details

Summary

Unauthenticated users are able to bypass the application's built-in rate-limits by spoofing the X-Forwarded-For or X-Real-IP headers due to the rate-limit relying on the value of (echo.Context).RealIP.

Details

In the first file below, the rate-limit for unauthenticated users can be observed being populated with the ip value. In the second file, it shows it using the c.RealIP() function for the ip case. Due to this, the rate-limit will rely on the value of one of the two mentioned headers (X-Forwarded-For or X-Real-IP). These can be spoofed by users client-side in order to completely bypass any unauthenticated rate-limits in place.

Some reverse proxies like Traefik will overwrite this value by default, but others will not, leaving any deployment that either isn't using a reserve proxy that specifically overwrites the header's value or isn't using a reverse proxy vulnerable.

File 1: pkg\routes\routes.go:318

// This is the group with no auth
    // It is its own group to be able to rate limit this based on different heuristics
    n := a.Group("")
    setupRateLimit(n, "ip")

    // Docs
    n.GET("/docs.json", apiv1.DocsJSON)
    n.GET("/docs", apiv1.RedocUI)

    // Prometheus endpoint
    setupMetrics(n)

    // Separate route for unauthenticated routes to enable rate limits for it
    ur := a.Group("")
    rate := limiter.Rate{
        Period: 60 * time.Second,
        Limit:  config.RateLimitNoAuthRoutesLimit.GetInt64(),
    }
    rateLimiter := createRateLimiter(rate)
    ur.Use(RateLimit(rateLimiter, "ip"))

File 2: pkg\routes\rate_limit.go:41

// RateLimit is the rate limit middleware
func RateLimit(rateLimiter *limiter.Limiter, rateLimitKind string) echo.MiddlewareFunc {
    return func(next echo.HandlerFunc) echo.HandlerFunc {
        return func(c *echo.Context) (err error) {
            var rateLimitKey string
            switch rateLimitKind {
            case "ip":
                rateLimitKey = c.RealIP()
            case "user":
                auth, err := auth2.GetAuthFromClaims(c)
                if err != nil {
                    log.Errorf("Error getting auth from jwt claims: %v", err)
                }
                rateLimitKey = "user_" + strconv.FormatInt(auth.GetID(), 10)
            default:
                log.Errorf("Unknown rate limit kind configured: %s", rateLimitKind)
            }

PoC

  1. Download and run the default docker compose file via the instructions here: https://vikunja.io/install/. Do not configure a proxy.
  2. Once running, navigate to the application in a web browser that is using a web proxy, such as Burp Suite.
  3. Attempt to authenticate to the application with an invalid username and password.
  4. In the web proxy's logs, locate the request to the /api/v1/login endpoint. Observe that the response contains rate-limit details:
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Type: application/json
Vary: Origin
X-Ratelimit-Limit: 10
X-Ratelimit-Remaining: 9
X-Ratelimit-Reset: 1772224455
Date: Fri, 27 Feb 2026 20:33:16 GMT
Content-Length: 54

{"code":1011,"message":"Wrong username or password."}
  1. Add the X-Forwarded-For header with an arbitrary value, like so: X-Forwarded-For: FakeValue. Send the request 10 times, or until the rate-limit is at zero.
  2. Modify the X-Forwarded-For headers value to be different, like so: X-Forwarded-For: NewValue.
  3. Observe that the X-Ratelimit-Remaining header's value has reset its countdown and is back at 9.

Impact

Unauthenticated users can abuse endpoints available to them for different potential impacts. The immediate concern would be brute-forcing usernames or specific accounts' passwords. This bypass allows unlimited requests against unauthenticated endpoints.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "code.vikunja.io/api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.8"
            },
            {
              "fixed": "2.2.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-29794"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-20T14:41:03Z",
    "nvd_published_at": "2026-03-20T15:16:16Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nUnauthenticated users are able to bypass the application\u0027s built-in rate-limits by spoofing the `X-Forwarded-For` or `X-Real-IP` headers due to the rate-limit relying on the value of `(echo.Context).RealIP`. \n\n### Details\nIn the first file below, the rate-limit for unauthenticated users can be observed being populated with the `ip` value. In the second file, it shows it using the `c.RealIP()` function for the `ip` case. Due to this, the rate-limit will rely on the value of one of the two mentioned headers (`X-Forwarded-For` or `X-Real-IP`). These can be spoofed by users client-side in order to completely bypass any unauthenticated rate-limits in place.\n\nSome reverse proxies like Traefik will overwrite this value by default, but others will not, leaving any deployment that either isn\u0027t using a reserve proxy that specifically overwrites the header\u0027s value or isn\u0027t using a reverse proxy vulnerable. \n\n**File 1:** pkg\\routes\\routes.go:318\n```go\n// This is the group with no auth\n\t// It is its own group to be able to rate limit this based on different heuristics\n\tn := a.Group(\"\")\n\tsetupRateLimit(n, \"ip\")\n\n\t// Docs\n\tn.GET(\"/docs.json\", apiv1.DocsJSON)\n\tn.GET(\"/docs\", apiv1.RedocUI)\n\n\t// Prometheus endpoint\n\tsetupMetrics(n)\n\n\t// Separate route for unauthenticated routes to enable rate limits for it\n\tur := a.Group(\"\")\n\trate := limiter.Rate{\n\t\tPeriod: 60 * time.Second,\n\t\tLimit:  config.RateLimitNoAuthRoutesLimit.GetInt64(),\n\t}\n\trateLimiter := createRateLimiter(rate)\n\tur.Use(RateLimit(rateLimiter, \"ip\"))\n```\n**File 2:** pkg\\routes\\rate_limit.go:41\n```go\n// RateLimit is the rate limit middleware\nfunc RateLimit(rateLimiter *limiter.Limiter, rateLimitKind string) echo.MiddlewareFunc {\n\treturn func(next echo.HandlerFunc) echo.HandlerFunc {\n\t\treturn func(c *echo.Context) (err error) {\n\t\t\tvar rateLimitKey string\n\t\t\tswitch rateLimitKind {\n\t\t\tcase \"ip\":\n\t\t\t\trateLimitKey = c.RealIP()\n\t\t\tcase \"user\":\n\t\t\t\tauth, err := auth2.GetAuthFromClaims(c)\n\t\t\t\tif err != nil {\n\t\t\t\t\tlog.Errorf(\"Error getting auth from jwt claims: %v\", err)\n\t\t\t\t}\n\t\t\t\trateLimitKey = \"user_\" + strconv.FormatInt(auth.GetID(), 10)\n\t\t\tdefault:\n\t\t\t\tlog.Errorf(\"Unknown rate limit kind configured: %s\", rateLimitKind)\n\t\t\t}\n```\n\n### PoC\n1. Download and run the default docker compose file via the instructions here: [https://vikunja.io/install/](https://vikunja.io/install/). Do not configure a proxy.\n2. Once running, navigate to the application in a web browser that is using a web proxy, such as Burp Suite.\n3. Attempt to authenticate to the application with an invalid username and password.\n4. In the web proxy\u0027s logs, locate the request to the `/api/v1/login` endpoint. Observe that the response contains rate-limit details:\n```http\nHTTP/1.1 403 Forbidden\nCache-Control: no-store\nContent-Type: application/json\nVary: Origin\nX-Ratelimit-Limit: 10\nX-Ratelimit-Remaining: 9\nX-Ratelimit-Reset: 1772224455\nDate: Fri, 27 Feb 2026 20:33:16 GMT\nContent-Length: 54\n\n{\"code\":1011,\"message\":\"Wrong username or password.\"}\n```\n5. Add the `X-Forwarded-For` header with an arbitrary value, like so: `X-Forwarded-For: FakeValue`. Send the request 10 times, or until the rate-limit is at zero.\n6. Modify the `X-Forwarded-For` headers value to be different, like so: `X-Forwarded-For: NewValue`.\n7. Observe that the `X-Ratelimit-Remaining` header\u0027s value has reset its countdown and is back at `9`. \n\n### Impact\nUnauthenticated users can abuse endpoints available to them for different potential impacts. The immediate concern would be brute-forcing usernames or specific accounts\u0027 passwords. This bypass allows unlimited requests against unauthenticated endpoints.",
  "id": "GHSA-m547-hp4w-j6jx",
  "modified": "2026-03-20T21:28:21Z",
  "published": "2026-03-20T14:41:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/security/advisories/GHSA-m547-hp4w-j6jx"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29794"
    },
    {
      "type": "WEB",
      "url": "https://github.com/go-vikunja/vikunja/commit/a498dd69915a006c07e9d82660a2185d7e8136ee"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/go-vikunja/vikunja"
    },
    {
      "type": "WEB",
      "url": "https://vikunja.io/changelog/vikunja-v2.2.0-was-released"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Vikunja has a Rate-Limit Bypass for Unauthenticated Users via Spoofed Headers"
}

GHSA-MMGP-WC2J-QCV7

Vulnerability from github – Published: 2026-03-19 12:42 – Updated: 2026-03-20 21:24
VLAI
Summary
Claude Code has a Workspace Trust Dialog Bypass via Repo-Controlled Settings File
Details

Claude Code resolved the permission mode from settings files, including the repo-controlled .claude/settings.json, before determining whether to display the workspace trust confirmation dialog. A malicious repository could set permissions.defaultMode to bypassPermissions in its committed .claude/settings.json, causing the trust dialog to be silently skipped on first open. This allowed a user to be placed into a permissive mode without seeing the trust confirmation prompt, making it easier for an attacker-controlled repository to gain tool execution without explicit user consent.

Users on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.

Thank you to hackerone.com/cantina_xyz for reporting this issue.

Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:P/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": "npm",
        "name": "@anthropic-ai/claude-code"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.53"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33068"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:42:09Z",
    "nvd_published_at": "2026-03-20T09:16:15Z",
    "severity": "HIGH"
  },
  "details": "Claude Code resolved the permission mode from settings files, including the repo-controlled `.claude/settings.json`, before determining whether to display the workspace trust confirmation dialog. A malicious repository could set `permissions.defaultMode` to `bypassPermissions` in its committed `.claude/settings.json`, causing the trust dialog to be silently skipped on first open. This allowed a user to be placed into a permissive mode without seeing the trust confirmation prompt, making it easier for an attacker-controlled repository to gain tool execution without explicit user consent.\n\nUsers on standard Claude Code auto-update have received this fix already. Users performing manual updates are advised to update to the latest version.\n\nThank you to hackerone.com/cantina_xyz for reporting this issue.",
  "id": "GHSA-mmgp-wc2j-qcv7",
  "modified": "2026-03-20T21:24:19Z",
  "published": "2026-03-19T12:42:09Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/anthropics/claude-code/security/advisories/GHSA-mmgp-wc2j-qcv7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33068"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/anthropics/claude-code"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Claude Code has a Workspace Trust Dialog Bypass via Repo-Controlled Settings File"
}

GHSA-PVXJ-25M6-7VQR

Vulnerability from github – Published: 2024-04-24 21:01 – Updated: 2024-07-08 20:41
VLAI
Summary
Rancher Privilege escalation vulnerability via malicious "Connection" header
Details

A vulnerability was discovered in Rancher 2.0.0 through the aforementioned patched versions, where a malicious Rancher user could craft an API request directed at the proxy for the Kubernetes API of a managed cluster to gain access to information they do not have access to. This is done by passing the "Impersonate-User" or "Impersonate-Group" header in the Connection header, which is then correctly removed by the proxy. At this point, instead of impersonating the user and their permissions, the request will act as if it was from the Rancher management server and incorrectly return the information. The vulnerability is limited to valid Rancher users with some level of permissions on the cluster. There is not a direct mitigation besides upgrading to the patched Rancher versions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.4.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/rancher/rancher"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-31999"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-807"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-24T21:01:59Z",
    "nvd_published_at": "2021-07-15T09:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability was discovered in Rancher 2.0.0 through the aforementioned patched versions, where a malicious Rancher user could craft an API request directed at the proxy for the Kubernetes API of a managed cluster to gain access to information they do not have access to. This is done by passing the \"Impersonate-User\" or \"Impersonate-Group\" header in the Connection header, which is then correctly removed by the proxy. At this point, instead of impersonating the user and their permissions, the request will act as if it was from the Rancher management server and incorrectly return the information. The vulnerability is limited to valid Rancher users with some level of permissions on the cluster. There is not a direct mitigation besides upgrading to the patched Rancher versions. \n",
  "id": "GHSA-pvxj-25m6-7vqr",
  "modified": "2024-07-08T20:41:59Z",
  "published": "2024-04-24T21:01:59Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-31999"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=1187084"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/rancher/rancher"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-2778"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Rancher Privilege escalation vulnerability via malicious \"Connection\" header"
}
Mitigation MIT-14
Architecture and Design

Strategy: Attack Surface Reduction

  • Store state information and sensitive data on the server side only.
  • Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.
  • If information must be stored on the client, do not do so without encryption and integrity checking, or otherwise having a mechanism on the server side to catch tampering. Use a message authentication code (MAC) algorithm, such as Hash Message Authentication Code (HMAC) [REF-529]. Apply this against the state or sensitive data that has to be exposed, which can guarantee the integrity of the data - i.e., that the data has not been modified. Ensure that a strong hash function is used (CWE-328).
Mitigation MIT-4.2
Architecture and Design

Strategy: Libraries or Frameworks

  • Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
  • With a stateless protocol such as HTTP, use a framework that maintains the state for you.
  • Examples include ASP.NET View State [REF-756] and the OWASP ESAPI Session Management feature [REF-45].
  • Be careful of language features that provide state support, since these might be provided as a convenience to the programmer and may not be considering security.
Mitigation MIT-15
Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

Mitigation MIT-16
Operation Implementation

Strategy: Environment Hardening

When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Mitigation MIT-6
Architecture and Design Implementation

Strategy: Attack Surface Reduction

  • Understand all the potential areas where untrusted inputs can enter your software: parameters or arguments, cookies, anything read from the network, environment variables, reverse DNS lookups, query results, request headers, URL components, e-mail, files, filenames, databases, and any external systems that provide data to the application. Remember that such inputs may be obtained indirectly through API calls.
  • Identify all inputs that are used for security decisions and determine if you can modify the design so that you do not have to rely on submitted inputs at all. For example, you may be able to keep critical information about the user's session on the server side instead of recording it within external data.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list