CWE-155
AllowedImproper Neutralization of Wildcards or Matching Symbols
Abstraction: Variant · Status: Draft
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could be interpreted as wildcards or matching symbols when they are sent to a downstream component.
36 vulnerabilities reference this CWE, most recent first.
GHSA-CCRR-HX7G-HMM4
Vulnerability from github – Published: 2024-09-10 06:30 – Updated: 2024-11-29 06:35Marinus Pfund, member of the AXIS OS Bug Bounty Program, has found the VAPIX API alwaysmulti.cgi was vulnerable for file globbing which could lead to resource exhaustion of the Axis device. Axis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.
{
"affected": [],
"aliases": [
"CVE-2024-6509"
],
"database_specific": {
"cwe_ids": [
"CWE-155",
"CWE-770"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-10T05:15:12Z",
"severity": "MODERATE"
},
"details": "Marinus Pfund, member of the AXIS OS Bug Bounty Program, \nhas found the VAPIX API alwaysmulti.cgi was vulnerable for file globbing which could lead to resource exhaustion of the Axis device. \nAxis has released patched AXIS OS versions for the highlighted flaw. Please refer to the Axis security advisory for more information and solution.",
"id": "GHSA-ccrr-hx7g-hmm4",
"modified": "2024-11-29T06:35:28Z",
"published": "2024-09-10T06:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-6509"
},
{
"type": "WEB",
"url": "https://www.axis.com/dam/public/47/bf/2c/cve-2024-6509-en-US-448996.pdf"
},
{
"type": "WEB",
"url": "https://www.axis.com/dam/public/f6/c6/f5/cve-2024-6509-en-US-458043.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F339-MQQR-7GVR
Vulnerability from github – Published: 2024-12-06 21:30 – Updated: 2024-12-06 21:30Ruijie Reyee OS versions 2.206.x up to but not including 2.320.x could allow an attacker to subscribe to partial possible topics in Ruijie MQTT broker, and receive partial messages being sent to and from devices.
{
"affected": [],
"aliases": [
"CVE-2024-47791"
],
"database_specific": {
"cwe_ids": [
"CWE-155"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-06T19:15:12Z",
"severity": "HIGH"
},
"details": "Ruijie Reyee OS versions 2.206.x up to but not including 2.320.x could allow an attacker to subscribe to partial possible topics in Ruijie MQTT broker, and receive partial messages being sent to and from devices.",
"id": "GHSA-f339-mqqr-7gvr",
"modified": "2024-12-06T21:30:39Z",
"published": "2024-12-06T21:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47791"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-24-338-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC: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-FC89-JGHX-8PVG
Vulnerability from github – Published: 2025-01-30 17:52 – Updated: 2025-02-05 16:23Impact
By design, AdmissionPolicy and AdmissionPolicyGroup can evaluate only namespaced resources. The resources to be evaluated are determined by the rules provided by the user when defining the policy. There might be Kubernetes namespaced resources that should not be validated by AdmissionPolicy and by the AdmissionPolicyGroup policies because of their sensitive nature. For example, PolicyReport are namespaced resources that contain the list of non compliant objects found inside of a namespace. See this section of Kubewarden’s documentation for more details about PolicyReport resources. An attacker can use either an AdmissionPolicy or an AdmissionPolicyGroup to prevent the creation and update of PolicyReport objects to hide non-compliant resources. Moreover, the same attacker might use a mutating AdmissionPolicy to alter the contents of the PolicyReport created inside of the namespace.
Patches
Starting from the 1.21.0 release, the validation rules applied to AdmissionPolicy and AdmissionPolicyGroup have been tightened to prevent them from validating sensitive types of namespaced resources. The new validation will also restrict the usage of wildcards when defining apiGroups and resources rules for AdmissionPolicy and AdmissionPolicyGroup objects.
Workarounds
On clusters running Kubewarden < 1.21.0, the following Kubewarden policy can be applied to prevent the creation of AdmissionPolicy and AdmissionPolicyGroup resources that interact with PolicyReport resources:
apiVersion: policies.kubewarden.io/v1
kind: ClusterAdmissionPolicy
metadata:
name: "deny-interaction-with-policyreport"
spec:
module: registry://ghcr.io/kubewarden/policies/cel-policy:latest
settings:
variables:
- name: hasWildcardInsideOfApiGroup
expression: "object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == '*'))"
- name: hasWildcardInsideOfResources
expression: "object.spec.rules.exists(r, r.resources.exists(ag, ag == '*' || ag == '*/*' || ag == 'policyreports/*'))"
- name: dealsWithPolicyReportApiGroup
expression: "object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == 'wgpolicyk8s.io'))"
- name: dealsWithPolicyReportResource
expression: "object.spec.rules.exists(r, r.resources.exists(ag, ag == 'policyreports' || ag == 'policyreports/'))"
- name: isPendingDeletion
expression: "has(object.metadata.deletionTimestamp)"
validations:
- expression: |
!( variables.hasWildcardInsideOfApiGroup ||
variables.hasWildcardInsideOfResources ||
variables.dealsWithPolicyReportResource ||
variables.dealsWithPolicyReportApiGroup
) || variables.isPendingDeletion
message: "cannot target PolicyReport resources or use wildcards in apiGroups or resources"
rules:
- apiGroups: ["policies.kubewarden.io"]
apiVersions: ["v1"]
operations: ["CREATE", "UPDATE"]
resources: ["admissionpolicies", "admissionpolicygroups"]
mutating: false
backgroundAudit: true
For more information
If you have any questions or comments about this advisory you can contact the Kubewarden team using the procedures described under the “security disclosure“ guidelines of the Kubewarden project.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kubewarden/kubewarden-controller"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.21.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-24376"
],
"database_specific": {
"cwe_ids": [
"CWE-155"
],
"github_reviewed": true,
"github_reviewed_at": "2025-01-30T17:52:37Z",
"nvd_published_at": "2025-01-30T16:15:31Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nBy design, AdmissionPolicy and AdmissionPolicyGroup can evaluate only namespaced resources. The resources to be evaluated are determined by the rules provided by the user when defining the policy.\nThere might be Kubernetes namespaced resources that should not be validated by AdmissionPolicy and by the AdmissionPolicyGroup policies because of their sensitive nature.\nFor example, PolicyReport are namespaced resources that contain the list of non compliant objects found inside of a namespace. See [this section](https://docs.kubewarden.io/explanations/audit-scanner/policy-reports) of Kubewarden\u2019s documentation for more details about PolicyReport resources.\nAn attacker can use either an AdmissionPolicy or an AdmissionPolicyGroup to prevent the creation and update of PolicyReport objects to hide non-compliant resources.\nMoreover, the same attacker might use a mutating AdmissionPolicy to alter the contents of the PolicyReport created inside of the namespace.\n\n### Patches\n\nStarting from the 1.21.0 release, the validation rules applied to AdmissionPolicy and AdmissionPolicyGroup have been tightened to prevent them from validating sensitive types of namespaced resources.\nThe new validation will also restrict the usage of wildcards when defining apiGroups and resources rules for AdmissionPolicy and AdmissionPolicyGroup objects.\n\n### Workarounds\n\nOn clusters running Kubewarden \u003c 1.21.0, the following Kubewarden policy can be applied to prevent the creation of AdmissionPolicy and AdmissionPolicyGroup resources that interact with PolicyReport resources:\n\n```yaml\napiVersion: policies.kubewarden.io/v1\nkind: ClusterAdmissionPolicy\nmetadata:\n name: \"deny-interaction-with-policyreport\"\nspec:\n module: registry://ghcr.io/kubewarden/policies/cel-policy:latest\n settings:\n variables:\n - name: hasWildcardInsideOfApiGroup\n expression: \"object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == \u0027*\u0027))\"\n - name: hasWildcardInsideOfResources\n expression: \"object.spec.rules.exists(r, r.resources.exists(ag, ag == \u0027*\u0027 || ag == \u0027*/*\u0027 || ag == \u0027policyreports/*\u0027))\"\n - name: dealsWithPolicyReportApiGroup\n expression: \"object.spec.rules.exists(r, r.apiGroups.exists(ag, ag == \u0027wgpolicyk8s.io\u0027))\"\n - name: dealsWithPolicyReportResource\n expression: \"object.spec.rules.exists(r, r.resources.exists(ag, ag == \u0027policyreports\u0027 || ag == \u0027policyreports/\u0027))\"\n - name: isPendingDeletion\n expression: \"has(object.metadata.deletionTimestamp)\"\n validations:\n - expression: |\n !( variables.hasWildcardInsideOfApiGroup ||\n variables.hasWildcardInsideOfResources ||\n variables.dealsWithPolicyReportResource ||\n variables.dealsWithPolicyReportApiGroup\n ) || variables.isPendingDeletion\n message: \"cannot target PolicyReport resources or use wildcards in apiGroups or resources\"\n rules:\n - apiGroups: [\"policies.kubewarden.io\"]\n apiVersions: [\"v1\"]\n operations: [\"CREATE\", \"UPDATE\"]\n resources: [\"admissionpolicies\", \"admissionpolicygroups\"]\n mutating: false\n backgroundAudit: true\n```\n\n### For more information\n\nIf you have any questions or comments about this advisory you can contact the Kubewarden team using the procedures described under the \u201c[security disclosure](https://docs.kubewarden.io/disclosure)\u201c guidelines of the Kubewarden project.",
"id": "GHSA-fc89-jghx-8pvg",
"modified": "2025-02-05T16:23:59Z",
"published": "2025-01-30T17:52:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubewarden/kubewarden-controller/security/advisories/GHSA-fc89-jghx-8pvg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-24376"
},
{
"type": "WEB",
"url": "https://github.com/kubewarden/kubewarden-controller/commit/8124039b5f0c955d0ee8c8ca12d4415282f02d2c"
},
{
"type": "PACKAGE",
"url": "https://github.com/kubewarden/kubewarden-controller"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2025-3434"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "KubeWarden\u0027s AdmissionPolicy and AdmissionPolicyGroup policies can be used to alter PolicyReport resources"
}
GHSA-R6WV-X735-W2V5
Vulnerability from github – Published: 2025-01-11 03:30 – Updated: 2026-01-23 22:06A wildcard expansion vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to enumerate files on the host filesystem.
{
"affected": [],
"aliases": [
"CVE-2025-0106"
],
"database_specific": {
"cwe_ids": [
"CWE-155"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T03:15:22Z",
"severity": "MODERATE"
},
"details": "A wildcard expansion vulnerability in Palo Alto Networks Expedition allows an unauthenticated attacker to enumerate files on the host filesystem.",
"id": "GHSA-r6wv-x735-w2v5",
"modified": "2026-01-23T22:06:23Z",
"published": "2025-01-11T03:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0106"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/PAN-SA-2025-0001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/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:N/R:U/V:C/RE:H/U:Green",
"type": "CVSS_V4"
}
]
}
GHSA-WPMR-8H3Q-FWJ7
Vulnerability from github – Published: 2026-09-10 21:23 – Updated: 2026-09-10 21:23Summary
On SQLite deployments, the lookup that maps an external identity to a local account does a substring match instead of an exact match. A subject value containing SQL wildcard characters therefore matches accounts the value was never issued for, and the sign-in binds to whichever account the database returns first, which can be an administrator. The same defect affects SCIM external-ID resolution. PostgreSQL deployments are not affected, because they take a separate and correct code path.
Preconditions
- The database is SQLite. This is the default backend. PostgreSQL deployments are not affected at all.
- OAuth or OIDC sign-in is configured, or SCIM provisioning is enabled. Both are off by default.
- For an attacker to steer the match deliberately, they must control the value of the claim Open WebUI uses as the subject. That value is normally assigned by the identity provider and is not attacker-controlled: the shipped GitHub and Feishu configurations use provider-assigned numeric identifiers, and a standard OIDC
subis provider-assigned. The deliberate case therefore requires an operator to have pointedOAUTH_SUB_CLAIMat a claim the end user can set at the identity provider, such as a username or email claim, or an identity provider that lets a user choose their own subject value. - No attacker and no misconfiguration are needed for the accidental case. A legitimate subject value that happens to contain an underscore matches other accounts as well, and which account is returned depends on database row order.
- For the SCIM path, the caller must already hold the SCIM bearer token, which is a privileged credential.
Impact
A sign-in can be bound to an account other than the one the identity provider authenticated. Where the operator has made the subject claim user-settable, an attacker who registers at that provider can choose a value that matches an existing account and receive a session for it, including an administrator account, which is a full compromise of the instance. Where the subject claim is provider-assigned, the deliberate attack is not available, and what remains is a correctness failure in which an ordinary subject value containing an underscore can resolve to the wrong account and hand one user another user's session non-deterministically.
The defect is in the identity match itself, so it is not mitigated by any downstream permission check: by the time a session is issued the wrong account has already been selected. It does not allow account creation, and it does not affect password sign-in, PostgreSQL deployments, or any deployment with OAuth, OIDC and SCIM all disabled.
Fix
Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28624. The two identity lookups now compare the nested JSON value directly through SQLAlchemy's JSON subscript operator, which emits an exact match on both supported databases, instead of going through the column-level contains() operator that degraded to a substring comparison on SQLite. The hand-written per-dialect branching is removed, since the operator already handles both backends.
Upgrading fully resolves it and no configuration change is required. Existing stored identities are unaffected, as the stored format does not change.
Root cause
backend/open_webui/models/users.py—get_user_by_oauth_sub, resolves an OAuth or OIDC identity to a local account.backend/open_webui/models/users.py—get_user_by_scim_external_id, the same pattern for SCIM.- Reached from the OAuth callback handler and the OAuth token-exchange handler, and from the SCIM user routes.
- Affects builds running on SQLite, which is the default database.
The oauth and scim columns are declared with SQLAlchemy's generic JSON type. That type does not implement a containment comparator, so a contains() call against it falls back to the generic string operator and compiles to a LIKE with the operand wrapped in % on both sides. The intent was a JSON containment test; what was emitted was a substring test against the serialized JSON, in which % and _ carry their usual LIKE meaning. The PostgreSQL branch was written separately against JSONB with an equality comparison and is correct, which is why the defect is confined to the default backend and why it survived review: the two branches look symmetrical and only one of them does what it appears to do.
Proof of concept
Against a SQLite instance with an OIDC provider configured, two accounts exist: an administrator whose stored subject is admin_sub_9999, and an ordinary user whose stored subject is bob_sub_1234. Both rows were seeded directly rather than created through a live provider sign-in; the lookup under test was then called as the application calls it.
Resolving the subject value % returns the administrator account. Resolving admin_sub_% likewise returns the administrator account. Resolving the correct full values returns the correct accounts, and resolving an unknown value returns nothing, so the failure is visible only when the supplied value contains a wildcard character. A subsequent check with an ordinary subject value containing an underscore showed it matching more than one account, with the returned account determined by row order.
Credits
Reported by @Classic298.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.6.41"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87016"
],
"database_specific": {
"cwe_ids": [
"CWE-155",
"CWE-287"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T21:23:25Z",
"nvd_published_at": "2026-09-09T22:18:46Z",
"severity": "HIGH"
},
"details": "## Summary\n\nOn SQLite deployments, the lookup that maps an external identity to a local account does a substring match instead of an exact match. A subject value containing SQL wildcard characters therefore matches accounts the value was never issued for, and the sign-in binds to whichever account the database returns first, which can be an administrator. The same defect affects SCIM external-ID resolution. PostgreSQL deployments are not affected, because they take a separate and correct code path.\n\n## Preconditions\n\n* The database is SQLite. This is the default backend. PostgreSQL deployments are not affected at all.\n* OAuth or OIDC sign-in is configured, or SCIM provisioning is enabled. Both are off by default.\n* For an attacker to steer the match deliberately, they must control the value of the claim Open WebUI uses as the subject. That value is normally assigned by the identity provider and is not attacker-controlled: the shipped GitHub and Feishu configurations use provider-assigned numeric identifiers, and a standard OIDC `sub` is provider-assigned. The deliberate case therefore requires an operator to have pointed `OAUTH_SUB_CLAIM` at a claim the end user can set at the identity provider, such as a username or email claim, or an identity provider that lets a user choose their own subject value.\n* No attacker and no misconfiguration are needed for the accidental case. A legitimate subject value that happens to contain an underscore matches other accounts as well, and which account is returned depends on database row order.\n* For the SCIM path, the caller must already hold the SCIM bearer token, which is a privileged credential.\n\n## Impact\n\nA sign-in can be bound to an account other than the one the identity provider authenticated. Where the operator has made the subject claim user-settable, an attacker who registers at that provider can choose a value that matches an existing account and receive a session for it, including an administrator account, which is a full compromise of the instance. Where the subject claim is provider-assigned, the deliberate attack is not available, and what remains is a correctness failure in which an ordinary subject value containing an underscore can resolve to the wrong account and hand one user another user\u0027s session non-deterministically.\n\nThe defect is in the identity match itself, so it is not mitigated by any downstream permission check: by the time a session is issued the wrong account has already been selected. It does not allow account creation, and it does not affect password sign-in, PostgreSQL deployments, or any deployment with OAuth, OIDC and SCIM all disabled.\n\n## Fix\n\nFixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28624. The two identity lookups now compare the nested JSON value directly through SQLAlchemy\u0027s JSON subscript operator, which emits an exact match on both supported databases, instead of going through the column-level `contains()` operator that degraded to a substring comparison on SQLite. The hand-written per-dialect branching is removed, since the operator already handles both backends.\n\nUpgrading fully resolves it and no configuration change is required. Existing stored identities are unaffected, as the stored format does not change.\n\n## Root cause\n\n* `backend/open_webui/models/users.py` \u2014 `get_user_by_oauth_sub`, resolves an OAuth or OIDC identity to a local account.\n* `backend/open_webui/models/users.py` \u2014 `get_user_by_scim_external_id`, the same pattern for SCIM.\n* Reached from the OAuth callback handler and the OAuth token-exchange handler, and from the SCIM user routes.\n* Affects builds running on SQLite, which is the default database.\n\nThe `oauth` and `scim` columns are declared with SQLAlchemy\u0027s generic `JSON` type. That type does not implement a containment comparator, so a `contains()` call against it falls back to the generic string operator and compiles to a `LIKE` with the operand wrapped in `%` on both sides. The intent was a JSON containment test; what was emitted was a substring test against the serialized JSON, in which `%` and `_` carry their usual `LIKE` meaning. The PostgreSQL branch was written separately against `JSONB` with an equality comparison and is correct, which is why the defect is confined to the default backend and why it survived review: the two branches look symmetrical and only one of them does what it appears to do.\n\n## Proof of concept\n\nAgainst a SQLite instance with an OIDC provider configured, two accounts exist: an administrator whose stored subject is `admin_sub_9999`, and an ordinary user whose stored subject is `bob_sub_1234`. Both rows were seeded directly rather than created through a live provider sign-in; the lookup under test was then called as the application calls it.\n\nResolving the subject value `%` returns the administrator account. Resolving `admin_sub_%` likewise returns the administrator account. Resolving the correct full values returns the correct accounts, and resolving an unknown value returns nothing, so the failure is visible only when the supplied value contains a wildcard character. A subsequent check with an ordinary subject value containing an underscore showed it matching more than one account, with the returned account determined by row order.\n\n## Credits\n\nReported by @Classic298.",
"id": "GHSA-wpmr-8h3q-fwj7",
"modified": "2026-09-10T21:23:25Z",
"published": "2026-09-10T21:23:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-wpmr-8h3q-fwj7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87016"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/28624"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/73c1f5806aeb6345dad5de8f5aa26d1f3d0bef80"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Sign-in as another user via wildcard characters in the OAuth subject claim on SQLite"
}
GHSA-XGGX-FX6W-V7CH
Vulnerability from github – Published: 2019-06-04 15:42 – Updated: 2021-08-04 20:41This affects Spring Data JPA in versions up to and including 2.1.6, 2.0.14 and 1.11.20. ExampleMatcher using ExampleMatcher.StringMatcher.STARTING, ExampleMatcher.StringMatcher.ENDING or ExampleMatcher.StringMatcher.CONTAINING could return more results than anticipated when a maliciously crafted example value is supplied.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.data:spring-data-jpa"
},
"ranges": [
{
"events": [
{
"introduced": "2.1.0"
},
{
"fixed": "2.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.14"
},
"package": {
"ecosystem": "Maven",
"name": "org.springframework.data:spring-data-jpa"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.1.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.springframework.data:spring-data-jpa"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.11.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-3802"
],
"database_specific": {
"cwe_ids": [
"CWE-155",
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2019-06-04T15:38:52Z",
"nvd_published_at": "2019-06-03T14:29:00Z",
"severity": "MODERATE"
},
"details": "This affects Spring Data JPA in versions up to and including 2.1.6, 2.0.14 and 1.11.20. ExampleMatcher using ExampleMatcher.StringMatcher.STARTING, ExampleMatcher.StringMatcher.ENDING or ExampleMatcher.StringMatcher.CONTAINING could return more results than anticipated when a maliciously crafted example value is supplied.",
"id": "GHSA-xggx-fx6w-v7ch",
"modified": "2021-08-04T20:41:46Z",
"published": "2019-06-04T15:42:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3802"
},
{
"type": "WEB",
"url": "https://pivotal.io/security/cve-2019-3802"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Neutralization of Wildcards or Matching Symbols"
}
Mitigation
Developers should anticipate that wildcard or matching elements will be injected/removed/manipulated in the input vectors of their product. Use an appropriate combination of denylists and allowlists to ensure only valid, expected and appropriate input is processed by the system.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation MIT-28
Strategy: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Mitigation MIT-20
Strategy: Input Validation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
No CAPEC attack patterns related to this CWE.