GHSA-8g98-m4j9-qww5:
Taylored webhook validation vulnerabilities
N/A
CVSS Score
Basic Information
CVE ID
-
GHSA ID
EPSS Score
-
CWE
Published
6/18/2025
Updated
6/18/2025
KEV Status
No
Technology
JavaScript
Technical Details
CVSS Vector
-
Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
---|---|---|---|
taylored | npm | >= 7.0.5, < 7.0.8 | 7.0.8 |
Vulnerability Intelligence
Miggo AI
Root Cause Analysis
The vulnerabilities reside in the 'Backend-in-a-Box' template (taysell-server
) generated by taylored
version 7.0.7. The analysis of the commit 57b7634391959dbbdb39b387ac4dc68157cd58a1
and the security advisory GHSA-8g98-m4j9-qww5 reveals several issues:
- Path Traversal: The
/get-patch
endpoint intemplates/backend-in-a-box/index.js
did not sanitize thepatchId
parameter, allowing arbitrary file reads. The vulnerable code pattern involved the direct use ofpatchId
inpath.join
. - Missing Webhook Validation: The
/paypal/webhook
endpoint intemplates/backend-in-a-box/index.js
did not verify the signature of incoming PayPal webhooks, allowing attackers to spoof purchase completion events. The patch added cryptographic verification. - Token Replay: The
/get-patch
endpoint allowed reuse of purchase tokens as it lacked a mechanism to mark tokens as used. The patch introduced thetoken_used_at
field and corresponding checks. - Insufficient PBKDF2 Iterations: Both the patch encryption function (
encryptAES256GCM
inlib/taysell-utils.ts
) and the decryption function (decryptAES256GCM
intemplates/backend-in-a-box/index.js
) used a low PBKDF2 iteration count (100,000), weakening the encryption. The patch increased this to 310,000.
The identified functions are the direct handlers of malicious input or perform cryptographic operations with weakened parameters. These functions would appear in runtime profiles or stack traces during exploitation or when processing affected data.
Vulnerable functions
handler.POST:/get-patch
templates/backend-in-a-box/index.js
This Express.js route handler was vulnerable to path traversal because it used the user-supplied `patchId` from the request body to construct a file path for patch download without proper sanitization. An attacker could provide a crafted `patchId` (e.g., `../../etc/passwd`) to read arbitrary files from the server. Additionally, it was vulnerable to purchase token replay because it did not invalidate purchase tokens after their first use, allowing a legitimate token to be reused indefinitely to download patches.
handler.POST:/paypal/webhook
templates/backend-in-a-box/index.js
This Express.js route handler was vulnerable because it processed incoming PayPal webhook notifications without cryptographically verifying their authenticity (e.g., checking the signature). An attacker could send a spoofed webhook request to this endpoint, tricking the server into believing a payment was successfully completed, thereby gaining unauthorized access to paid patches.
decryptAES256GCM
templates/backend-in-a-box/index.js
This function, responsible for decrypting patches in the backend server, used PBKDF2 for key derivation with an insufficient number of iterations (100,000). This made the encryption weaker and more susceptible to offline brute-force attacks if an attacker obtained an encrypted patch file and had or could guess the encryption key.
encryptAES256GCM
lib/taysell-utils.ts
This function, used by the `taylored` CLI tool to encrypt commercial patches before they are uploaded to the server, employed PBKDF2 for key derivation with an insufficient number of iterations (100,000). This resulted in patches being encrypted with a weaker key, making them more susceptible to brute-force attacks if the encrypted files were obtained by an attacker.