CVE-2024-57075

What it actually does

A prototype-pollution flaw in the lib.Logger function of eazy-logger 4.0.1 lets untrusted object properties be merged onto JavaScript’s shared Object.prototype. Once the prototype chain is polluted, subsequent object lookups, iteration, or logging can throw, hang, or recurse, crashing or stalling the Node.js process (availability-only impact; confidentiality and integrity are not indicated).

Why it matters to the business

Applications that pass user-controlled objects into this logger can be taken offline without authentication, causing service interruption, failed jobs, and operational recovery work. Exploit probability remains low (EPSS about 0.0057 with a negligible 30-day rise, exploit maturity none, not in CISA KEV, no ransomware use reported) despite the CVE being roughly 600 days old, so treat as a standard high-availability hygiene item rather than an emergency campaign.

How an attack unfolds

An unauthenticated remote attacker finds an application that feeds request bodies, query objects, or configuration maps into eazy-logger’s Logger. They submit a crafted object that uses prototype-pollution property names. Unsafe assignment inside Logger writes those keys onto Object.prototype. Later application or framework code that assumes clean objects then misbehaves or throws, producing a denial of service until the process is restarted and the polluted state is gone. No named threat actors or mass exploitation are associated with this issue.

How to fix it

Remove or replace eazy-logger 4.0.1; pin a patched release if the maintainer publishes one, otherwise stop passing untrusted objects into Logger and switch to a maintained logger. Do not merge user-controlled objects into options or log metadata. Reject or strip prototype-pollution keys at the trust boundary, prefer null-prototype objects or Maps for untrusted data, and consider freezing Object.prototype in hardened runtimes. Rebuild and redeploy so lockfiles no longer resolve 4.0.1.

How to confirm the fix worked

Inventory package-lock.json, yarn.lock, and pnpm-lock.yaml for eazy-logger 4.0.1 (direct and transitive). After upgrade or removal, confirm the resolved version is no longer 4.0.1 and that Logger is not invoked with untrusted objects. Run dependency scanners and a staging smoke test of logging paths using only benign objects; do not use pollution payloads in production.

Typical attack path

1. Identify a reachable Node.js service that depends on eazy-logger and accepts structured input that reaches Logger.
2. Send unauthenticated requests containing object keys intended to pollute the prototype chain.
3. Trigger Logger so those keys are assigned onto Object.prototype.
4. Cause follow-on application logic or logging to fail, hang, or crash the process.
5. Repeat as needed to keep the service unavailable after restarts.

How to detect it

There is no public in-the-wild exploitation, so hunt for attempts and crash artifacts rather than a known campaign. Review reverse-proxy, WAF, and application access logs for request bodies or query strings containing prototype-pollution property names aimed at services that log structured input. Correlate those requests with Node.js process exits, uncaught-exception logs, event-loop stalls, container restarts, and crash dumps around eazy-logger or generic logger stack frames. Host forensics should note sudden availability loss without a corresponding deploy.

• "__proto__"
• constructor.prototype
• "prototype":
• eazy-logger
• lib.Logger

What your security team should do

• Prioritize inventory of Node.js apps that still resolve eazy-logger 4.0.1; this is availability-focused hygiene, not a KEV emergency.
• Upgrade, replace, or isolate the logger so untrusted input cannot reach Logger.
• Add request-body validation that drops prototype-pollution keys at API edges.
• Watch for unexplained Node process crashes or restart loops on services that log structured user input.
• Track maintainer advisories for an official fixed version and pin it when available.