Rapid7 updated a Metasploit auxiliary scanner module that detects XML external entity injection in Elasticsearch via Apache Tika.
A commit in the Metasploit Framework updated modules/auxiliary/scanner/http/elasticsearch_tika_xfa_xxe.rb, an auxiliary scanner module. The module targets XML external entity (XXE) injection in Elasticsearch through Apache Tika, and was co-authored by jheysel-r7. The terse commit message contains no additional details, CVE references, or exploitation notes.
Exposed Vietnam-linked APIS database held 220.8 million passenger and crew records with passport and flight data from January 2017 to April 2026.
Kinryū Labs discovered an exposed Elasticsearch cluster named 'pax-info' containing 220.8 million passenger and crew records, about 107 GB across 29 indices, hosted on IP space assigned to Viettel in Hanoi. The records include names, birth dates, nationalities, passport numbers, and detailed flight information from airlines across Asia-Pacific, Europe and the Middle East. Researchers reported the exposure on June 3 and the database was secured by June 8 with Singapore Airlines coordinating; no evidence of theft was found, but missing server logs mean access cannot be ruled out.
Elastic compares SIEM data egress cost, latency, and fidelity across CrowdStrike, Microsoft, Google, and Splunk, arguing vendors engineer lock-in.
Elastic Security Labs published an opinion piece comparing how major SIEM and security vendors handle data egress, based on each vendor's public documentation as of September 2026. It rates CrowdStrike Falcon Data Replicator and Palo Alto Networks XSIAM Event Forwarding as restricted (paid add-ons with batch delays), Microsoft as partially open, Splunk as open, and Elastic as open with no export license. The piece argues frictionless ingestion paired with licensed or delayed egress is an intentional lock-in business model, and cites CrowdStrike's 2026 Global Threat Report eCrime breakout time of 29 minutes to argue real-time telemetry access is now essential.
Apache Log4j 2 RCE CVE-2021-44228 is actively exploited via crafted JNDI lookups; Palo Alto Unit 42 urges upgrading to Log4j 2.17.1.
Unit 42 details CVE-2021-44228, an easily exploited remote code execution flaw in Apache Log4j 2 where attacker-supplied JNDI lookups in logged user input cause payload download and execution. Massive internet-wide scanning for unpatched systems has begun, with observed follow-on activity including information stealing, Cobalt Strike delivery, and coinmining. The recommended fix is Log4j 2.17.1, which also patches CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832. Widely used Java software including Apache Struts, Solr, Druid, Flink, ElasticSearch, and Spring Boot is affected.
JNDI Injection Remote Code Execution in Apache Log4j2 (Log4Shell)
Apache Log4j2, an extremely widely used Java logging library, fails to protect its JNDI lookup feature against attacker-controlled JNDI-related endpoints (CWE-20, CWE-502), so crafted text processed by the logger causes the Java runtime to fetch and load attacker-supplied objects, leading to remote code execution. The flaw is triggered whenever attacker-controlled input reaches the logging API and is parsed for JNDI lookups, a pattern common in web servers and enterprise Java applications that log user-supplied fields such as headers or form values. Successful exploitation yields arbitrary code execution under the privileges of the affected application, giving attackers a foothold for lateral movement, data theft, and ransomware deployment. Any Java application or product that ships or bundles an affected Apache Log4j2 release is exposed, making this one of the most broadly deployed vulnerabilities ever disclosed. Exploitation is confirmed in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2021-12-10 with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days.
Remote Code Execution in Apache Log4j2 via Incomplete Log4Shell Fix
CVE-2021-45046 is a remote code execution and information disclosure flaw in Apache Log4j2 (CWE-917) that resulted from an incomplete fix to CVE-2021-44228 (Log4Shell), leaving the Thread Context Lookup Pattern vulnerable in certain non-default configurations. It is triggered when an application logs attacker-controlled data using layouts or patterns that perform Thread Context (MDC) lookups, allowing crafted lookup expressions to be evaluated against untrusted input. A successful attacker can achieve remote code execution, or potentially information disclosure, on the affected service. Any deployment of Apache Log4j2 that relies on the affected non-default lookup configurations is exposed, which given Log4j2's ubiquity in Java applications and embedded products means a very large installed base. Exploitation is confirmed: the flaw is in CISA KEV (added 2023-05-01) with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days.
· Apache Log4j2 Log4j 2.x; per Apache advisory, 2.0-beta9 through 2.15.0 (and 2.16.0 in some non-default configurations), fixed in 2.17.0 and in 2.12.3/2.3.1 for older branches KEV ransomwaremass
In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially c
In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code
Included in Log4j 1.2 is a SocketServer class that is vulnerable to deserialization of untrusted data which can be exploited to remotely execute arbitrary code when combined with a deserialization gadget when listening to untrusted network traffic for log data. This affects Log4j versions up to 1.2 up to 1.2.17.
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a
Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack when a configuration uses a JDBC Appender with a JNDI LDAP data source URI when an attacker has control of the target LDAP server. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups.
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1.
Entities are extracted by the model from each article. Watching an entity keeps it in this browser only (no account); the watchlist page and dashboard alerts use it.