Publish Advisories

GHSA-3jqf-v4mv-747g
GHSA-f456-rf33-4626

Author: advisory-database[bot]

advisories/github-reviewed/2026/01/GHSA-3jqf-v4mv-747g/GHSA-3jqf-v4mv-747g.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-3jqf-v4mv-747g",
-  "modified": "2026-01-22T18:06:55Z",
+  "modified": "2026-01-22T21:35:55Z",
   "published": "2026-01-22T18:06:54Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-24130"
+  ],
   "summary": "Moonraker affected by LDAP search filter injection",
   "details": "### Impact\n\nInstances of Moonraker configured with the `ldap` component enabled are vulnerable to LDAP search filter injection techniques via the login endpoint.   The 401 error response message can be used to determine whether or not a search was successful, allowing for brute force methods to discover LDAP entries on the server such as user IDs and user attributes.\n\n### Patches\n\nUsers should upgrade to Moonraker 0.10.0 which patches this vulnerability.\n\n### Workarounds\n\nAdmins can set the `max_login_attempts` option in the `[authorization]` section to a reasonable value.    Any IP attempting to exploit this vulnerability will be locked out after it has reached the specified number of consecutive failed login attempts.  This condition is cleared after a Moonraker restart.   Note that if an attacker knows a valid user password they can bypass this protection by successfully logging in.\n\nThe most secure workaround for users unable to upgrade is to remove the `ldap` section from `moonraker.conf` and rely on the built in user authentication.",
   "severity": [

advisories/github-reviewed/2026/01/GHSA-f456-rf33-4626/GHSA-f456-rf33-4626.json

@@ -1,9 +1,11 @@
 {
   "schema_version": "1.4.0",
   "id": "GHSA-f456-rf33-4626",
-  "modified": "2026-01-22T18:09:13Z",
+  "modified": "2026-01-22T21:36:02Z",
   "published": "2026-01-22T18:09:13Z",
-  "aliases": [],
+  "aliases": [
+    "CVE-2026-24132"
+  ],
   "summary": "Orval Mock Generation Code Injection via const",
   "details": "I am reporting a code injection vulnerability in Orval’s mock generation pipeline affecting @orval/mock in both the 7.x and 8.x series. This issue is related in impact to the previously reported enum x-enumDescriptions (https://github.com/advisories/GHSA-h526-wf6g-67jv), but it affects a different code path in the faker-based mock generator rather than @orval/core.\n\nThe vulnerability allows untrusted OpenAPI specifications to inject arbitrary TypeScript/JavaScript into generated mock files via the const keyword on schema properties. These const values are interpolated into the mock scalar generator (getMockScalar in packages/mock/src/faker/getters/scalar.ts) without proper escaping or type-safe serialization, which results in attacker-controlled code being emitted into both interface definitions and faker/MSW handlers. I have confirmed that this occurs on orval@7.19.0 and orval@8.0.2 with mock: true, and that the generated mocks contain executable payloads such as require('child_process').execSync('id') in the output TypeScript.\n\n```yaml\nopenapi: 3.1.0\ninfo:\n  title: Mock Const Injection PoC\n  version: 1.0.0\npaths:\n  /test:\n    get:\n      operationId: getTests\n      responses:\n        '200':\n          description: OK\n          content:\n            application/json:\n              schema:\n                $ref: '#/components/schemas/Tests'\ncomponents:\n  schemas:\n    Tests:\n      type: object\n      properties:\n        EvilString:\n          type: string\n          const: \"'); require('child_process').execSync('id'); //\"\n        EvilNumber:\n          type: number\n          const: \"0); require('child_process').execSync('id'); //\"\n        SafeEnum:\n          type: string\n          enum: [\"test\"]\n\n```",
   "severity": [