CVE-2018-3745

What it actually does

The vulnerable atob package passes attacker-controlled input directly to the Node.js Buffer constructor. On Node.js 4.x and earlier, calling Buffer with a number allocates an uninitialized memory buffer of that size rather than decoding Base64 input. If an application exposes atob to untrusted input, a remote unauthenticated attacker can supply numeric input and cause the process to return fragments of uninitialized process memory and/or allocate very large buffers that exhaust memory. The main technical risks are sensitive memory disclosure and denial of service in applications running vulnerable atob versions on legacy Node.js runtimes.

Why it matters to the business

Applications that still run legacy Node.js 4.x or earlier and depend on atob 2.0.3 or older may unintentionally expose secrets or customer data from process memory and may be crashed remotely through memory exhaustion. Although this issue is old and not listed in CISA KEV, public exploit knowledge exists, the CVSS severity is high, and the affected pattern is common in older JavaScript dependency trees, so organizations should treat remaining exposure as a legacy-risk cleanup priority.

How an attack unfolds

An attacker first identifies an application endpoint, API parameter, WebSocket message, or server-side code path that accepts user-controlled input and decodes it using the vulnerable atob package. Instead of sending a Base64 string, the attacker sends a numeric value. In Node.js 4.x and earlier, the package calls Buffer with that number, causing Node.js to allocate an uninitialized buffer of the requested size. If the application returns the decoded value, logs it, embeds it in an error response, or otherwise exposes it, the attacker may receive stale process memory that can contain tokens, secrets, request data, or other sensitive fragments. By using large numeric values or repeated requests, the attacker may also force excessive memory allocation and crash or destabilize the Node.js process.

How to fix it

Upgrade the atob dependency to a maintained version newer than 2.0.3, preferably the latest available release, and regenerate lockfiles so transitive copies are also updated. If using exact package remediation, ensure no installed dependency resolves to atob 2.0.3 or earlier. Upgrade the Node.js runtime to a supported modern LTS version; Node.js 4.x and earlier are end-of-life and contain unsafe Buffer behavior that makes this issue exploitable. Where immediate upgrades are not possible, validate input before Base64 decoding and reject non-string values, numeric JSON values, extremely large inputs, and unexpected encodings. Replace unsafe Buffer constructor patterns with Buffer.from(input, 'base64') and add size limits around decoded data.

How to confirm the fix worked

Confirm the deployed application no longer contains atob 2.0.3 or earlier by reviewing package-lock.json, npm-shrinkwrap.json, yarn.lock, pnpm-lock.yaml, and the deployed node_modules tree. Confirm the runtime is not Node.js 4.x or earlier by checking node --version in build and production images. Test affected endpoints with numeric input where Base64 strings are expected and verify the request is rejected with a validation error rather than returning decoded data, memory-like binary output, or causing process instability. Run dependency scanners such as npm audit, SCA tooling, or lockfile-based checks to verify the vulnerable package is absent from all deployable artifacts and container images.

Typical attack path

1. Find a Node.js application or service that uses the atob package and accepts attacker-controlled data for Base64 decoding.
2. Confirm the application is running a vulnerable dependency version, atob 2.0.3 or earlier, on Node.js 4.x or earlier.
3. Send a numeric value where a Base64 string is expected, such as a JSON number or numeric query/body parameter.
4. Trigger the vulnerable Buffer allocation path inside atob.
5. Collect returned, logged, or reflected output that may contain uninitialized process memory, or repeat with large values to cause memory exhaustion.
6. Use any disclosed secrets, tokens, or internal data to support follow-on access, or use repeated requests to degrade service availability.

How to detect it

There is no highly reliable network-only indicator for this vulnerability because exploitation depends on how an application passes input to atob and whether the output is returned or logged. Review HTTP access logs, API gateway logs, WAF logs, application logs, and APM traces for requests where Base64-related fields or parameters contain JSON numbers or unusually large numeric strings instead of Base64 text. Focus on parameters and fields named like token, data, payload, encoded, base64, auth, blob, image, file, or content. Look for 500 errors, process restarts, out-of-memory events, container OOMKills, abrupt Node.js exits, or responses containing non-printable/binary-looking data after such requests. On hosts and containers, review package manifests and lockfiles for atob 2.0.3 or earlier and correlate exposure with externally reachable routes. If memory disclosure is plausible, examine application responses and logs around suspicious requests for fragments of secrets, HTTP headers, environment variables, JWTs, cookies, or credentials, and rotate any potentially exposed secrets.

• node_modules/atob/
• "atob": "2.0.3"
• "atob": "2.0.2"
• "atob": "2.0.1"
• "atob": "2.0.0"
• "atob":"2.0.3"
• "atob":"2.0.2"
• "atob":"2.0.1"
• "atob":"2.0.0"
• Buffer(str, 'base64')
• Buffer(str,"base64")
• Buffer(input, 'base64')
• Buffer(input,"base64")
• FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
• JavaScript heap out of memory
• OOMKilled
• GET /?data=100000000
• payload=100000000
• base64=100000000
• encoded=100000000

What your security team should do

• Prioritize inventory of Node.js applications running Node.js 4.x or earlier, because the runtime behavior is a prerequisite for reliable exploitation.
• Search all source repositories and deployed artifacts for atob 2.0.3 or earlier, including transitive dependencies in lockfiles.
• Upgrade atob to a maintained release newer than 2.0.3 and move affected services to a supported Node.js LTS runtime.
• Add application-layer validation so Base64 decode routines accept only strings and enforce strict maximum input sizes.
• Review externally exposed endpoints that perform Base64 decoding for unauthenticated access and add tests for numeric input handling.
• Monitor application logs and APM data for memory spikes, process restarts, and unusual requests containing numeric values in Base64-related parameters.
• If exploitation is suspected, rotate secrets that may have resided in Node.js process memory, including API keys, session signing keys, OAuth tokens, and service credentials.