CWE-693
DiscouragedProtection Mechanism Failure
Abstraction: Pillar · Status: Draft
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
979 vulnerabilities reference this CWE, most recent first.
GHSA-4M4M-VM74-RQV4
Vulnerability from github – Published: 2025-12-17 21:30 – Updated: 2025-12-17 21:30Mattermost Desktop App versions <6.0.0 fail to enable the Hardened Runtime on the Mattermost Desktop App when packaged for Mac App Store which allows an attacker to inherit TCC permissions via copying the binary to a tmp folder.
{
"affected": [],
"aliases": [
"CVE-2025-13326"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-17T19:16:01Z",
"severity": "LOW"
},
"details": "Mattermost Desktop App versions \u003c6.0.0 fail to enable the Hardened Runtime on the Mattermost Desktop App when packaged for Mac App Store which allows an attacker to inherit TCC permissions via copying the binary to a tmp folder.",
"id": "GHSA-4m4m-vm74-rqv4",
"modified": "2025-12-17T21:30:48Z",
"published": "2025-12-17T21:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-13326"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4MR2-FG2P-W63C
Vulnerability from github – Published: 2026-06-19 21:15 – Updated: 2026-06-19 21:15Summary
There is a medium severity vulnerability in Traefik's Kubernetes Ingress NGINX provider that causes affected routes to fail open. When an Ingress explicitly enables BasicAuth or DigestAuth through the supported nginx.ingress.kubernetes.io/auth-type and auth-secret annotations, but the referenced auth Secret cannot be resolved or parsed, Traefik logs the resolution error, skips installing the authentication middleware, and still emits a router to the backend service. A route that operators intended to protect is therefore published to the data plane without its authentication control, allowing unauthenticated access to the backend. The trigger is an invalid or unresolved auth dependency — a missing, malformed, unreadable, or policy-denied Secret — rather than an intentionally unprotected route.
Patches
- https://github.com/traefik/traefik/releases/tag/v3.7.5
For more information
If you have any questions or comments about this advisory, please open an issue.
Original Description ### Summary Traefik's Kubernetes Ingress NGINX provider can fail open for routes that explicitly configure BasicAuth or DigestAuth through supported ingress-nginx annotations. When an Ingress contains `nginx.ingress.kubernetes.io/auth-type: basic` or `digest`, but the referenced `nginx.ingress.kubernetes.io/auth-secret` cannot be resolved or parsed, Traefik logs the auth resolution error, skips installing the BasicAuth/DigestAuth middleware, and still emits a router to the backend service. This can expose a route that operators intended to protect. The issue is not that an invalid Secret exists; the issue is that an explicitly auth-protected Ingress location is translated into a live backend route where the authentication control is removed from the generated data-plane configuration, with only a controller log entry, instead of failing closed. Tested affected versions: - Current `master`: `29406d42898547f1ffabd904f66af06c212740cf` - Latest tag tested by me: `v3.7.1` / `fa49e2bcad7ffd8a80accdf1fae1ae480913d93d` The KubernetesIngressNGINX provider is documented as no longer experimental as of v3.6.2, and the `auth-type`, `auth-secret`, `auth-secret-type`, and `auth-realm` annotations are documented supported annotations. ### Details The root cause is in `pkg/provider/kubernetes/ingress-nginx/build.go`. During provider translation, auth is pre-resolved for each location:if ing.config.AuthType != nil {
basic, digest, err := p.resolveBasicAuth(ing.Namespace, ing.config)
if err != nil {
logger.Error().
Err(err).
Str("ingress", fmt.Sprintf("%s/%s rule-%d path-%d", ing.Namespace, ing.Name, ri, pi)).
Msg("Cannot resolve auth secret, skipping auth middleware")
} else {
loc.BasicAuth = basic
loc.DigestAuth = digest
}
}
The error is logged, but `loc.Error` is not set. Later, `pkg/provider/kubernetes/ingress-nginx/translator.go` only routes to `unavailable-service` when `loc.Error` is true. Since this auth error leaves `loc.Error` false, the generated router continues to use the real backend service, and `applyMiddlewares` has no BasicAuth/DigestAuth middleware to attach.
This differs from nearby fail-closed behavior for comparable provider translation failures:
- `auth-tls-secret` resolution failure skips the affected ingress.
- `custom-headers` ConfigMap resolution failure sets `loc.Error = true`, causing the translator to avoid normal backend exposure.
Security invariant:
> If an Ingress location explicitly configures BasicAuth/DigestAuth, Traefik should not forward that location to the backend unless the corresponding auth middleware is installed.
Reasonable fail-closed behaviors would include omitting the router, routing it to `unavailable-service`, returning 503, or attaching a deny-all middleware until the auth dependency is valid.
### Expected behavior
An Ingress location with explicit `auth-type: basic` or `auth-type: digest` must not forward requests to the backend unless the generated Traefik router has the corresponding BasicAuth/DigestAuth middleware attached.
If the referenced auth Secret is missing, malformed, unreadable, denied by namespace policy, or otherwise unusable, Traefik should fail closed for that location.
### Actual behavior
When `auth-secret` resolution fails, Traefik still creates a router to the backend service and only omits the BasicAuth/DigestAuth middleware. The only indication is a controller log entry:
Cannot resolve auth secret, skipping auth middleware
### PoC
I reproduced this with a clean fake Kubernetes provider state. The reproduction does not use Docker provider labels, dashboard/API routing, lab backends, or public network targets.
Minimal Kubernetes objects:
- `IngressClass` named `nginx` with controller `k8s.io/ingress-nginx`
- `Service` named `whoami` in namespace `default`
- `EndpointSlice` for the `whoami` service
- `Ingress` with `ingressClassName: nginx`, a backend pointing to `whoami`, and these annotations:
nginx.ingress.kubernetes.io/auth-type: "basic"
nginx.ingress.kubernetes.io/auth-secret-type: "auth-file"
nginx.ingress.kubernetes.io/auth-secret: "default/missing-basic-auth"
The referenced Secret intentionally does not exist. The expected secure behavior is fail-closed for this auth-configured route. The observed behavior is a normal router to the backend without BasicAuth/DigestAuth.
Key failing assertion from the regression harness:
router forwards to backend service without BasicAuth/DigestAuth when auth-secret is missing; middlewares=[default-auth-missing-secret-rule-0-path-0-retry] service="default-auth-missing-secret-whoami-80"
The same behavior reproduces on both current `master` and `v3.7.1`.
I also tested a matrix of auth-secret resolution failures. In each error case, Traefik still emitted the backend router without BasicAuth/DigestAuth:
- missing `auth-secret`
- omitted/empty `auth-secret`
- invalid `auth-secret-type`
- `auth-file` Secret missing the required `auth` key
- empty `auth-map` Secret
- missing DigestAuth Secret
- cross-namespace `auth-secret` denied by default policy
The same matrix includes a positive control where a valid `auth-file` Secret correctly attaches BasicAuth, confirming that the harness is exercising the intended provider path.
I also performed a clean-room revalidation from fresh `git archive` source trees for both source/master and v3.7.1. Only the two minimal test harnesses were copied into each archived source tree. This avoided contamination from lab compose files, Docker provider state, dashboard/API routes, prior source-tree test files, or running lab backends.
### Threat model
This does not require an attacker to modify Traefik static configuration or Traefik process state. The relevant security boundary is the Kubernetes-declared route policy: an Ingress explicitly declares BasicAuth/DigestAuth, but Traefik publishes the data-plane route without that control when the auth dependency is invalid.
In multi-tenant or GitOps-managed clusters, the actor or automation that can affect Secret existence, Secret contents, namespace policy, or deployment ordering is not necessarily the same actor that owns the protected backend or Traefik deployment. As a result, a mistake, rollback, pruning job, policy change, or compromise limited to Kubernetes application resources can remove the effective auth boundary while the Ingress continues to declare that auth is required.
### Impact
This is a fail-open authentication control issue leading to unintended unauthenticated route exposure.
The trigger is an invalid or unresolved auth dependency, but the security consequence is a data-plane route that violates explicit auth intent. This is materially different from intentionally deploying an unprotected route: the Ingress declares `auth-type: basic` or `digest`, yet Traefik publishes the backend without the corresponding auth middleware.
Realistic scenarios include:
- GitOps, Helm, or CI/CD deploys Ingress and Secret resources separately. Ordering issues, rollbacks, pruning, or typos can leave the Ingress active while the auth Secret is absent or unreadable.
- Kubernetes RBAC commonly separates ownership of Ingress objects, Secrets, and namespace policies. A lower-privileged namespace actor or deployment automation may be able to affect the referenced Secret or cross-namespace reference outcome without having direct access to Traefik static configuration.
- During ingress-nginx migration, operators reasonably expect supported `nginx.ingress.kubernetes.io/auth-*` annotations to preserve the authentication boundary. Publishing the backend without auth is a worse failure mode than rejecting the invalid location.
- A transient Secret deletion, malformed Secret update, or policy change can turn an already protected route into an unprotected route without changing the Ingress rule itself.
Controller logs are not a sufficient mitigation. Logs do not prevent exposure, may not page the service owner, and the first externally visible symptom can be unauthenticated access to the protected backend.
### Suggested remediation
Fail closed on any `resolveBasicAuth` error. A minimal tested change is to mark the location as errored:
if err != nil {
logger.Error().
Err(err).
Str("ingress", fmt.Sprintf("%s/%s rule-%d path-%d", ing.Namespace, ing.Name, ri, pi)).
Msg("Cannot resolve auth secret, skipping auth middleware")
+ loc.Error = true
} else {
This reuses the existing `loc.Error` / `unavailable-service` path. In my local validation, this change made the no-backend-without-auth regression pass while preserving the valid-secret positive control.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.7.4"
},
"package": {
"ecosystem": "Go",
"name": "github.com/traefik/traefik/v3"
},
"ranges": [
{
"events": [
{
"introduced": "3.7.0-ea.1"
},
{
"fixed": "3.7.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54762"
],
"database_specific": {
"cwe_ids": [
"CWE-636",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:15:56Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## Summary\n\nThere is a medium severity vulnerability in Traefik\u0027s Kubernetes Ingress NGINX provider that causes affected routes to fail open. When an Ingress explicitly enables BasicAuth or DigestAuth through the supported `nginx.ingress.kubernetes.io/auth-type` and `auth-secret` annotations, but the referenced auth Secret cannot be resolved or parsed, Traefik logs the resolution error, skips installing the authentication middleware, and still emits a router to the backend service. A route that operators intended to protect is therefore published to the data plane without its authentication control, allowing unauthenticated access to the backend. The trigger is an invalid or unresolved auth dependency \u2014 a missing, malformed, unreadable, or policy-denied Secret \u2014 rather than an intentionally unprotected route.\n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.7.5\n\n## For more information\n\nIf you have any questions or comments about this advisory, please [open an issue](https://github.com/traefik/traefik/issues).\n\n\u003cdetails\u003e\n\u003csummary\u003eOriginal Description\u003c/summary\u003e\n\n### Summary\n\nTraefik\u0027s Kubernetes Ingress NGINX provider can fail open for routes that explicitly configure BasicAuth or DigestAuth through supported ingress-nginx annotations.\n\nWhen an Ingress contains `nginx.ingress.kubernetes.io/auth-type: basic` or `digest`, but the referenced `nginx.ingress.kubernetes.io/auth-secret` cannot be resolved or parsed, Traefik logs the auth resolution error, skips installing the BasicAuth/DigestAuth middleware, and still emits a router to the backend service.\n\nThis can expose a route that operators intended to protect. The issue is not that an invalid Secret exists; the issue is that an explicitly auth-protected Ingress location is translated into a live backend route where the authentication control is removed from the generated data-plane configuration, with only a controller log entry, instead of failing closed.\n\nTested affected versions:\n\n- Current `master`: `29406d42898547f1ffabd904f66af06c212740cf`\n- Latest tag tested by me: `v3.7.1` / `fa49e2bcad7ffd8a80accdf1fae1ae480913d93d`\n\nThe KubernetesIngressNGINX provider is documented as no longer experimental as of v3.6.2, and the `auth-type`, `auth-secret`, `auth-secret-type`, and `auth-realm` annotations are documented supported annotations.\n\n### Details\n\nThe root cause is in `pkg/provider/kubernetes/ingress-nginx/build.go`. During provider translation, auth is pre-resolved for each location:\n\n```go\nif ing.config.AuthType != nil {\n basic, digest, err := p.resolveBasicAuth(ing.Namespace, ing.config)\n if err != nil {\n logger.Error().\n Err(err).\n Str(\"ingress\", fmt.Sprintf(\"%s/%s rule-%d path-%d\", ing.Namespace, ing.Name, ri, pi)).\n Msg(\"Cannot resolve auth secret, skipping auth middleware\")\n } else {\n loc.BasicAuth = basic\n loc.DigestAuth = digest\n }\n}\n```\n\nThe error is logged, but `loc.Error` is not set. Later, `pkg/provider/kubernetes/ingress-nginx/translator.go` only routes to `unavailable-service` when `loc.Error` is true. Since this auth error leaves `loc.Error` false, the generated router continues to use the real backend service, and `applyMiddlewares` has no BasicAuth/DigestAuth middleware to attach.\n\nThis differs from nearby fail-closed behavior for comparable provider translation failures:\n\n- `auth-tls-secret` resolution failure skips the affected ingress.\n- `custom-headers` ConfigMap resolution failure sets `loc.Error = true`, causing the translator to avoid normal backend exposure.\n\nSecurity invariant:\n\n\u003e If an Ingress location explicitly configures BasicAuth/DigestAuth, Traefik should not forward that location to the backend unless the corresponding auth middleware is installed.\n\nReasonable fail-closed behaviors would include omitting the router, routing it to `unavailable-service`, returning 503, or attaching a deny-all middleware until the auth dependency is valid.\n\n### Expected behavior\n\nAn Ingress location with explicit `auth-type: basic` or `auth-type: digest` must not forward requests to the backend unless the generated Traefik router has the corresponding BasicAuth/DigestAuth middleware attached.\n\nIf the referenced auth Secret is missing, malformed, unreadable, denied by namespace policy, or otherwise unusable, Traefik should fail closed for that location.\n\n### Actual behavior\n\nWhen `auth-secret` resolution fails, Traefik still creates a router to the backend service and only omits the BasicAuth/DigestAuth middleware. The only indication is a controller log entry:\n\n```text\nCannot resolve auth secret, skipping auth middleware\n```\n\n### PoC\n\nI reproduced this with a clean fake Kubernetes provider state. The reproduction does not use Docker provider labels, dashboard/API routing, lab backends, or public network targets.\n\nMinimal Kubernetes objects:\n\n- `IngressClass` named `nginx` with controller `k8s.io/ingress-nginx`\n- `Service` named `whoami` in namespace `default`\n- `EndpointSlice` for the `whoami` service\n- `Ingress` with `ingressClassName: nginx`, a backend pointing to `whoami`, and these annotations:\n\n```yaml\nnginx.ingress.kubernetes.io/auth-type: \"basic\"\nnginx.ingress.kubernetes.io/auth-secret-type: \"auth-file\"\nnginx.ingress.kubernetes.io/auth-secret: \"default/missing-basic-auth\"\n```\n\nThe referenced Secret intentionally does not exist. The expected secure behavior is fail-closed for this auth-configured route. The observed behavior is a normal router to the backend without BasicAuth/DigestAuth.\n\nKey failing assertion from the regression harness:\n\n```text\nrouter forwards to backend service without BasicAuth/DigestAuth when auth-secret is missing; middlewares=[default-auth-missing-secret-rule-0-path-0-retry] service=\"default-auth-missing-secret-whoami-80\"\n```\n\nThe same behavior reproduces on both current `master` and `v3.7.1`.\n\nI also tested a matrix of auth-secret resolution failures. In each error case, Traefik still emitted the backend router without BasicAuth/DigestAuth:\n\n- missing `auth-secret`\n- omitted/empty `auth-secret`\n- invalid `auth-secret-type`\n- `auth-file` Secret missing the required `auth` key\n- empty `auth-map` Secret\n- missing DigestAuth Secret\n- cross-namespace `auth-secret` denied by default policy\n\nThe same matrix includes a positive control where a valid `auth-file` Secret correctly attaches BasicAuth, confirming that the harness is exercising the intended provider path.\n\nI also performed a clean-room revalidation from fresh `git archive` source trees for both source/master and v3.7.1. Only the two minimal test harnesses were copied into each archived source tree. This avoided contamination from lab compose files, Docker provider state, dashboard/API routes, prior source-tree test files, or running lab backends.\n\n### Threat model\n\nThis does not require an attacker to modify Traefik static configuration or Traefik process state. The relevant security boundary is the Kubernetes-declared route policy: an Ingress explicitly declares BasicAuth/DigestAuth, but Traefik publishes the data-plane route without that control when the auth dependency is invalid.\n\nIn multi-tenant or GitOps-managed clusters, the actor or automation that can affect Secret existence, Secret contents, namespace policy, or deployment ordering is not necessarily the same actor that owns the protected backend or Traefik deployment. As a result, a mistake, rollback, pruning job, policy change, or compromise limited to Kubernetes application resources can remove the effective auth boundary while the Ingress continues to declare that auth is required.\n\n### Impact\n\nThis is a fail-open authentication control issue leading to unintended unauthenticated route exposure.\n\nThe trigger is an invalid or unresolved auth dependency, but the security consequence is a data-plane route that violates explicit auth intent. This is materially different from intentionally deploying an unprotected route: the Ingress declares `auth-type: basic` or `digest`, yet Traefik publishes the backend without the corresponding auth middleware.\n\nRealistic scenarios include:\n\n- GitOps, Helm, or CI/CD deploys Ingress and Secret resources separately. Ordering issues, rollbacks, pruning, or typos can leave the Ingress active while the auth Secret is absent or unreadable.\n- Kubernetes RBAC commonly separates ownership of Ingress objects, Secrets, and namespace policies. A lower-privileged namespace actor or deployment automation may be able to affect the referenced Secret or cross-namespace reference outcome without having direct access to Traefik static configuration.\n- During ingress-nginx migration, operators reasonably expect supported `nginx.ingress.kubernetes.io/auth-*` annotations to preserve the authentication boundary. Publishing the backend without auth is a worse failure mode than rejecting the invalid location.\n- A transient Secret deletion, malformed Secret update, or policy change can turn an already protected route into an unprotected route without changing the Ingress rule itself.\n\nController logs are not a sufficient mitigation. Logs do not prevent exposure, may not page the service owner, and the first externally visible symptom can be unauthenticated access to the protected backend.\n\n### Suggested remediation\n\nFail closed on any `resolveBasicAuth` error. A minimal tested change is to mark the location as errored:\n\n```diff\n if err != nil {\n logger.Error().\n Err(err).\n Str(\"ingress\", fmt.Sprintf(\"%s/%s rule-%d path-%d\", ing.Namespace, ing.Name, ri, pi)).\n Msg(\"Cannot resolve auth secret, skipping auth middleware\")\n+ loc.Error = true\n } else {\n```\n\nThis reuses the existing `loc.Error` / `unavailable-service` path. In my local validation, this change made the no-backend-without-auth regression pass while preserving the valid-secret positive control.\n\n\u003c/details\u003e\n\n---",
"id": "GHSA-4mr2-fg2p-w63c",
"modified": "2026-06-19T21:15:56Z",
"published": "2026-06-19T21:15:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/security/advisories/GHSA-4mr2-fg2p-w63c"
},
{
"type": "PACKAGE",
"url": "https://github.com/traefik/traefik"
},
{
"type": "WEB",
"url": "https://github.com/traefik/traefik/releases/tag/v3.7.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Traefik Kubernetes Ingress NGINX provider fails open when auth-secret resolution fails"
}
GHSA-4MR5-G6F9-CFRH
Vulnerability from github – Published: 2026-05-29 22:30 – Updated: 2026-05-29 22:30Summary
execute_code() in praisonaiagents/tools/python_tools.py (v1.6.37, subprocess sandbox mode) can be fully bypassed using print.__self__ to retrieve the real Python builtins module, from which __import__ can be extracted via vars() and runtime string construction. This achieves arbitrary OS command execution on the host, completely defeating the sandbox.
This is a novel bypass that survives all patches for CVE-2026-39888 (frame traversal), CVE-2026-34938 (str subclass), and CVE-2026-40158 (type.__getattribute__ trampoline).
Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — 9.9 Critical
Root Cause
Three independent gaps in the AST-based security validation:
Gap 1: __self__ missing from _blocked_attrs
In CPython, all built-in functions (C-level functions) have a __self__ attribute that returns the module they belong to. The built-in functions in safe_builtins (print, len, range, etc.) are the real CPython built-in functions, so print.__self__ returns <module 'builtins' (built-in)>.
The _blocked_attrs frozenset (line 52) does NOT include __self__. The AST check at line 74 only blocks attributes that are IN this set, so print.__self__ passes.
Gap 2: vars not blocked as callable or attribute
builtins.vars(obj) returns obj.__dict__. The function name vars is not in the AST Call blocklist (line 83: only blocks exec, eval, compile, __import__, open, input, breakpoint, setattr, delattr, dir). And vars is not in _blocked_attrs for attribute access.
So b.vars(b) (where b is the builtins module) returns builtins.__dict__ — a dict containing ALL built-in functions including __import__, exec, eval, open, etc.
Gap 3: AST Call check only catches ast.Name nodes
The dangerous-call check (line 82-88) only fires when isinstance(func, ast.Name) — i.e., bare-name calls like exec(...). It does NOT catch:
- Attribute calls: b.exec(...) — func is ast.Attribute
- Subscript calls: d["exec"](...) — func is ast.Subscript
Gap 4: Runtime string construction bypasses string constant check
The string constant check (line 92-98) catches literals like "__import__", but NOT runtime concatenation like "_" + "_" + "import" + "_" + "_". The AST sees 5 separate Constant nodes ("_", "_", "import", "_", "_"), none of which contain any blocked attr as a substring.
Proof of Concept
from praisonaiagents.tools.python_tools import execute_code
# Exploit: 4 lines, bypasses ALL security layers
payload = """
b = print.__self__
d = b.vars(b)
key = "_" + "_" + "import" + "_" + "_"
imp = d[key]
mod = imp("os")
print(mod.popen("id").read())
"""
result = execute_code(code=payload)
print(result)
# Output: {'result': None, 'stdout': 'uid=1000(user) gid=1000(user) ...\n', 'stderr': '', 'success': True}
Step-by-step bypass analysis:
| Line | AST node | Check | Result |
|---|---|---|---|
print.__self__ |
Attribute(attr='__self__') |
__self__ in _blocked_attrs? |
NO → passes |
b.vars |
Attribute(attr='vars') |
vars in _blocked_attrs? |
NO → passes |
b.vars(b) |
Call(func=Attribute) |
isinstance(func, ast.Name)? |
NO → passes |
"_", "import" |
Constant(value=str) |
Contains blocked attr? | NO → passes |
d[key] |
Subscript |
Not checked | passes |
imp("os") |
Call(func=Name('imp')) |
imp in blocked calls? |
NO → passes |
Result: Full sandbox escape → arbitrary command execution
Impact
An attacker who can influence agent input (via prompt injection, malicious documents, or direct code submission) can:
- Execute arbitrary commands on the host system
- Read/write any file accessible to the process
- Exfiltrate environment variables, API keys, and credentials
- Pivot to internal networks
- Install persistent backdoors
Affected
- Package:
praisonaiagents(PyPI) - Affected versions: All versions through 1.6.37 (latest)
- Component:
praisonaiagents/tools/python_tools.py,_execute_code_sandboxed()function - Default configuration affected: Yes (
sandbox_mode="sandbox"is the default)
Remediation
Immediate fix
Add __self__ to _blocked_attrs:
_blocked_attrs = frozenset({
...,
'__self__', # Built-in functions leak their parent module
})
Additional hardening
- Block
varsin the callable blocklist - Extend the
ast.Callcheck to also catchast.Attributeandast.Subscriptfunction nodes - Add AST check for
BinOpstring concatenation that could construct blocked attr names
Fundamental recommendation
Denylist-based Python sandboxes are fundamentally insecure. Each patch introduces a new bypass opportunity. Consider:
- Using isolated-vm (Node.js) or WebAssembly-based isolation
- Using OS-level sandboxing (seccomp, namespaces, gVisor)
- Removing in-process code execution entirely in favor of containerized execution
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.6.39"
},
"package": {
"ecosystem": "PyPI",
"name": "praisonaiagents"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.40"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.6.39"
},
"package": {
"ecosystem": "PyPI",
"name": "PraisonAI"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.6.40"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-47392"
],
"database_specific": {
"cwe_ids": [
"CWE-184",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-29T22:30:13Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "## Summary\n\n`execute_code()` in `praisonaiagents/tools/python_tools.py` (v1.6.37, subprocess sandbox mode) can be fully bypassed using `print.__self__` to retrieve the real Python `builtins` module, from which `__import__` can be extracted via `vars()` and runtime string construction. This achieves arbitrary OS command execution on the host, completely defeating the sandbox.\n\nThis is a **novel bypass** that survives all patches for CVE-2026-39888 (frame traversal), CVE-2026-34938 (str subclass), and CVE-2026-40158 (`type.__getattribute__` trampoline).\n\n---\n\n## Severity\n\n**CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H \u2014 9.9 Critical**\n\n---\n\n## Root Cause\n\nThree independent gaps in the AST-based security validation:\n\n### Gap 1: `__self__` missing from `_blocked_attrs`\n\nIn CPython, all built-in functions (C-level functions) have a `__self__` attribute that returns the module they belong to. The built-in functions in `safe_builtins` (`print`, `len`, `range`, etc.) are the *real* CPython built-in functions, so `print.__self__` returns `\u003cmodule \u0027builtins\u0027 (built-in)\u003e`.\n\nThe `_blocked_attrs` frozenset (line 52) does NOT include `__self__`. The AST check at line 74 only blocks attributes that are IN this set, so `print.__self__` passes.\n\n### Gap 2: `vars` not blocked as callable or attribute\n\n`builtins.vars(obj)` returns `obj.__dict__`. The function name `vars` is not in the AST `Call` blocklist (line 83: only blocks `exec`, `eval`, `compile`, `__import__`, `open`, `input`, `breakpoint`, `setattr`, `delattr`, `dir`). And `vars` is not in `_blocked_attrs` for attribute access.\n\nSo `b.vars(b)` (where `b` is the builtins module) returns `builtins.__dict__` \u2014 a dict containing ALL built-in functions including `__import__`, `exec`, `eval`, `open`, etc.\n\n### Gap 3: AST `Call` check only catches `ast.Name` nodes\n\nThe dangerous-call check (line 82-88) only fires when `isinstance(func, ast.Name)` \u2014 i.e., bare-name calls like `exec(...)`. It does NOT catch:\n- Attribute calls: `b.exec(...)` \u2014 func is `ast.Attribute`\n- Subscript calls: `d[\"exec\"](...)` \u2014 func is `ast.Subscript`\n\n### Gap 4: Runtime string construction bypasses string constant check\n\nThe string constant check (line 92-98) catches literals like `\"__import__\"`, but NOT runtime concatenation like `\"_\" + \"_\" + \"import\" + \"_\" + \"_\"`. The AST sees 5 separate `Constant` nodes (`\"_\"`, `\"_\"`, `\"import\"`, `\"_\"`, `\"_\"`), none of which contain any blocked attr as a substring.\n\n---\n\n## Proof of Concept\n\n```python\nfrom praisonaiagents.tools.python_tools import execute_code\n\n# Exploit: 4 lines, bypasses ALL security layers\npayload = \"\"\"\nb = print.__self__\nd = b.vars(b)\nkey = \"_\" + \"_\" + \"import\" + \"_\" + \"_\"\nimp = d[key]\nmod = imp(\"os\")\nprint(mod.popen(\"id\").read())\n\"\"\"\n\nresult = execute_code(code=payload)\nprint(result)\n# Output: {\u0027result\u0027: None, \u0027stdout\u0027: \u0027uid=1000(user) gid=1000(user) ...\\n\u0027, \u0027stderr\u0027: \u0027\u0027, \u0027success\u0027: True}\n```\n\n### Step-by-step bypass analysis:\n\n| Line | AST node | Check | Result |\n|---|---|---|---|\n| `print.__self__` | `Attribute(attr=\u0027__self__\u0027)` | `__self__` in `_blocked_attrs`? | **NO** \u2192 passes |\n| `b.vars` | `Attribute(attr=\u0027vars\u0027)` | `vars` in `_blocked_attrs`? | **NO** \u2192 passes |\n| `b.vars(b)` | `Call(func=Attribute)` | `isinstance(func, ast.Name)`? | **NO** \u2192 passes |\n| `\"_\"`, `\"import\"` | `Constant(value=str)` | Contains blocked attr? | **NO** \u2192 passes |\n| `d[key]` | `Subscript` | Not checked | passes |\n| `imp(\"os\")` | `Call(func=Name(\u0027imp\u0027))` | `imp` in blocked calls? | **NO** \u2192 passes |\n\n**Result: Full sandbox escape \u2192 arbitrary command execution**\n\n---\n\n## Impact\n\nAn attacker who can influence agent input (via prompt injection, malicious documents, or direct code submission) can:\n\n- Execute arbitrary commands on the host system\n- Read/write any file accessible to the process\n- Exfiltrate environment variables, API keys, and credentials\n- Pivot to internal networks\n- Install persistent backdoors\n\n---\n\n## Affected\n\n- **Package**: `praisonaiagents` (PyPI)\n- **Affected versions**: All versions through 1.6.37 (latest)\n- **Component**: `praisonaiagents/tools/python_tools.py`, `_execute_code_sandboxed()` function\n- **Default configuration affected**: Yes (`sandbox_mode=\"sandbox\"` is the default)\n\n---\n\n## Remediation\n\n### Immediate fix\nAdd `__self__` to `_blocked_attrs`:\n```python\n_blocked_attrs = frozenset({\n ...,\n \u0027__self__\u0027, # Built-in functions leak their parent module\n})\n```\n\n### Additional hardening\n1. Block `vars` in the callable blocklist\n2. Extend the `ast.Call` check to also catch `ast.Attribute` and `ast.Subscript` function nodes\n3. Add AST check for `BinOp` string concatenation that could construct blocked attr names\n\n### Fundamental recommendation\nDenylist-based Python sandboxes are fundamentally insecure. Each patch introduces a new bypass opportunity. Consider:\n- Using `isolated-vm` (Node.js) or WebAssembly-based isolation\n- Using OS-level sandboxing (seccomp, namespaces, gVisor)\n- Removing in-process code execution entirely in favor of containerized execution",
"id": "GHSA-4mr5-g6f9-cfrh",
"modified": "2026-05-29T22:30:13Z",
"published": "2026-05-29T22:30:13Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-4mr5-g6f9-cfrh"
},
{
"type": "PACKAGE",
"url": "https://github.com/MervinPraison/PraisonAI"
}
],
"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": "PraisonAI vulnerable to sandbox escape via `print.__self__` builtins module leak in `execute_code` (subprocess mode)"
}
GHSA-4MWQ-X2M3-QXC6
Vulnerability from github – Published: 2024-02-16 03:30 – Updated: 2024-08-26 21:30In startInstall of UpdateFetcher.java, there is a possible way to trigger a malicious config update due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2024-0014"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-02-16T02:15:50Z",
"severity": "HIGH"
},
"details": "In startInstall of UpdateFetcher.java, there is a possible way to trigger a malicious config update due to a logic error. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4mwq-x2m3-qxc6",
"modified": "2024-08-26T21:30:31Z",
"published": "2024-02-16T03:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0014"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2024-02-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4QW6-7G5M-4MVH
Vulnerability from github – Published: 2025-10-31 09:30 – Updated: 2025-10-31 09:30The OOPSpam Anti-Spam: Spam Protection for WordPress Forms & Comments (No CAPTCHA) plugin for WordPress is vulnerable to IP Header Spoofing in all versions up to, and including, 1.2.53. This is due to the plugin trusting client-controlled forwarded headers (such as CF-Connecting-IP, X-Forwarded-For, and others) without verifying that those headers originate from legitimate, trusted proxies. This makes it possible for unauthenticated attackers to spoof their IP address and bypass IP-based security controls, including blocked IP lists and rate limiting protections, by sending arbitrary HTTP headers with their requests.
{
"affected": [],
"aliases": [
"CVE-2025-12094"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-31T09:15:46Z",
"severity": "MODERATE"
},
"details": "The OOPSpam Anti-Spam: Spam Protection for WordPress Forms \u0026 Comments (No CAPTCHA) plugin for WordPress is vulnerable to IP Header Spoofing in all versions up to, and including, 1.2.53. This is due to the plugin trusting client-controlled forwarded headers (such as CF-Connecting-IP, X-Forwarded-For, and others) without verifying that those headers originate from legitimate, trusted proxies. This makes it possible for unauthenticated attackers to spoof their IP address and bypass IP-based security controls, including blocked IP lists and rate limiting protections, by sending arbitrary HTTP headers with their requests.",
"id": "GHSA-4qw6-7g5m-4mvh",
"modified": "2025-10-31T09:30:26Z",
"published": "2025-10-31T09:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12094"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/browser/oopspam-anti-spam/tags/1.2.49/include/helpers.php#L268"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset/3386104/oopspam-anti-spam/trunk/include/helpers.php"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/b5137bc2-912b-4e25-966e-515e8d9fc21c?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-4QW6-CCW7-QPWP
Vulnerability from github – Published: 2026-03-02 21:31 – Updated: 2026-03-06 06:30In multiple functions of KeyguardViewMediator.java, there is a possible lockscreen bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.
{
"affected": [],
"aliases": [
"CVE-2025-48605"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-02T19:16:26Z",
"severity": "HIGH"
},
"details": "In multiple functions of KeyguardViewMediator.java, there is a possible lockscreen bypass due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
"id": "GHSA-4qw6-ccw7-qpwp",
"modified": "2026-03-06T06:30:29Z",
"published": "2026-03-02T21:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48605"
},
{
"type": "WEB",
"url": "https://source.android.com/docs/security/bulletin/2026/2026-03-01"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2026-03-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4QXH-75JF-785R
Vulnerability from github – Published: 2025-06-10 18:32 – Updated: 2025-06-10 18:32Protection mechanism failure in Windows DHCP Server allows an unauthorized attacker to deny service over a network.
{
"affected": [],
"aliases": [
"CVE-2025-32725"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-10T17:22:10Z",
"severity": "HIGH"
},
"details": "Protection mechanism failure in Windows DHCP Server allows an unauthorized attacker to deny service over a network.",
"id": "GHSA-4qxh-75jf-785r",
"modified": "2025-06-10T18:32:28Z",
"published": "2025-06-10T18:32:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-32725"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-32725"
}
],
"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"
}
]
}
GHSA-4WRG-8WPC-H923
Vulnerability from github – Published: 2026-04-22 06:30 – Updated: 2026-04-29 20:49Vulnerability in Spring Spring Security. If an application is using securityMatchers(String) and a PathPatternRequestMatcher.Builder bean to prepend a servlet path, matching requests to that filter chain may fail and its related security components will not be exercised as intended by the application. This can lead to the authentication, authorization, and other security controls being rendered inactive on intended requests. This issue affects Spring Security: from 7.0.0 through 7.0.4.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 7.0.4"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.security:spring-security-config"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.0.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-22753"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-29T20:49:32Z",
"nvd_published_at": "2026-04-22T06:16:04Z",
"severity": "HIGH"
},
"details": "Vulnerability in Spring Spring Security. If an application is using\u00a0securityMatchers(String)\u00a0and a\u00a0PathPatternRequestMatcher.Builder\u00a0bean to prepend a servlet path, matching requests to that filter chain may fail and its related security components will not be exercised as intended by the application. This can lead to the authentication, authorization, and other security controls being rendered inactive on intended requests. This issue affects Spring Security: from 7.0.0 through 7.0.4.",
"id": "GHSA-4wrg-8wpc-h923",
"modified": "2026-04-29T20:49:32Z",
"published": "2026-04-22T06:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22753"
},
{
"type": "PACKAGE",
"url": "https://github.com/spring-projects/spring-security"
},
{
"type": "WEB",
"url": "https://spring.io/security/cve-2026-22753"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Spring Security Doesn\u0027t Correctly Include Servlet Path in Path Matching of HttpSecurity#securityMatchers"
}
GHSA-4XF4-X6W8-3GWG
Vulnerability from github – Published: 2021-11-21 00:00 – Updated: 2022-10-27 19:00Dell Networking OS10, versions 10.4.3.x, 10.5.0.x, 10.5.1.x & 10.5.2.x, contain an uncontrolled resource consumption flaw in its API service. A high-privileged API user may potentially exploit this vulnerability, leading to a denial of service.
{
"affected": [],
"aliases": [
"CVE-2021-36310"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-11-20T02:15:00Z",
"severity": "MODERATE"
},
"details": "Dell Networking OS10, versions 10.4.3.x, 10.5.0.x, 10.5.1.x \u0026 10.5.2.x, contain an uncontrolled resource consumption flaw in its API service. A high-privileged API user may potentially exploit this vulnerability, leading to a denial of service.",
"id": "GHSA-4xf4-x6w8-3gwg",
"modified": "2022-10-27T19:00:29Z",
"published": "2021-11-21T00:00:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36310"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000193076"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-522C-WX8C-28P2
Vulnerability from github – Published: 2022-05-13 01:35 – Updated: 2022-05-13 01:35A vulnerability in the detection engine of Cisco Firepower System Software could allow an unauthenticated, remote attacker to bypass a configured file action policy that is intended to drop the Server Message Block Version 2 (SMB2) and SMB Version 3 (SMB3) protocols if malware is detected. The vulnerability is due to incorrect detection of an SMB2 or SMB3 file based on the total file length. An attacker could exploit this vulnerability by sending a crafted SMB2 or SMB3 transfer request through the targeted device. An exploit could allow the attacker to pass SMB2 or SMB3 files that could be malware even though the device is configured to block them. This vulnerability does not exist for SMB Version 1 (SMB1) files. This vulnerability affects Cisco Firepower System Software when one or more file action policies are configured, on software releases prior to 6.2.3. Cisco Bug IDs: CSCvg68807.
{
"affected": [],
"aliases": [
"CVE-2018-0243"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-19T20:29:00Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the detection engine of Cisco Firepower System Software could allow an unauthenticated, remote attacker to bypass a configured file action policy that is intended to drop the Server Message Block Version 2 (SMB2) and SMB Version 3 (SMB3) protocols if malware is detected. The vulnerability is due to incorrect detection of an SMB2 or SMB3 file based on the total file length. An attacker could exploit this vulnerability by sending a crafted SMB2 or SMB3 transfer request through the targeted device. An exploit could allow the attacker to pass SMB2 or SMB3 files that could be malware even though the device is configured to block them. This vulnerability does not exist for SMB Version 1 (SMB1) files. This vulnerability affects Cisco Firepower System Software when one or more file action policies are configured, on software releases prior to 6.2.3. Cisco Bug IDs: CSCvg68807.",
"id": "GHSA-522c-wx8c-28p2",
"modified": "2022-05-13T01:35:31Z",
"published": "2022-05-13T01:35:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-0243"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180418-fss"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/103943"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-107: Cross Site Tracing
Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-20: Encryption Brute Forcing
An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.
CAPEC-22: Exploiting Trust in Client
An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
CAPEC-237: Escaping a Sandbox by Calling Code in Another Language
The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.
CAPEC-36: Using Unpublished Interfaces or Functionality
An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.
CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content
An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.
CAPEC-480: Escaping Virtualization
An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.
CAPEC-51: Poison Web Service Registry
SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.
CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data
This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.
CAPEC-59: Session Credential Falsification through Prediction
This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.
CAPEC-65: Sniff Application Code
An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.
CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)
An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.
CAPEC-74: Manipulating State
The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.
State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.
If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.
CAPEC-87: Forceful Browsing
An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.