Tag: Infosec

  • RubyGems Under Siege: New Account Registrations Suspended After Massive Malware Incursion

    RubyGems has temporarily suspended the registration of new accounts following a pervasive assault on the Ruby ecosystem. According to investigators, adversaries disseminated hundreds of deleterious packages—some tailored to compromise specific enterprises, while others functioned as versatile instruments for broader exploitation.

    The breach was publicly delineated by Maciej Mensfeld, Senior Product Manager for Supply Chain Security at Mend.io. He noted that the magnitude of the incursion, involving hundreds of compromised components, necessitated an immediate cessation of new account creations. The registration portal now explicitly states that new applications are currently being declined.

    Mend.io, which collaborates in fortifying RubyGems, has withheld granular technical specifics for the duration of the containment effort, promising a comprehensive disclosure once the threat is localized. As of the current briefing, the identity of the perpetrators remains obscured.

    This incident reflects a burgeoning trend of offensives targeting open-source repositories. Malicious actors increasingly leverage popular package managers as a conduit to infiltrate developer infrastructures. A single compromised dependency can permeate the projects of myriad corporations, subsequently providing a gateway to exfiltrate access tokens, cryptographic keys, and other sensitive telemetry.

    Recently, Google observed that credentials purloined through such maneuvers are being monetized through affiliations with syndicates specializing in extortion, data theft, and the distribution of malware. Their report specifically highlights instances where threat actors, including TeamPCP, compromised widely utilized packages to propagate information-stealing software.

    Regarding the RubyGems situation, the primary mitigation strategy has been the moratorium on new registrations. This decisive action restricts the ability of adversaries to rapidly generate ephemeral accounts and distribute further malicious code while the security team audits the extent of the contagion and purges the repository.

  • Root Access & DNS Hijacking: Critical Dnsmasq Flaws Threaten Millions of Routers and Virtual Machines

    A suite of vulnerabilities has been unearthed within ubiquitous networking systems, where a conventional domain query could potentially misdirect a user and a modest network service could be transformed into an adversarial foothold. The flaws reside in dnsmasq, a versatile utility that often operates inconspicuously yet governs essential functions in routers, virtual machines, and specialized distributions.

    Forensic analysts identified six vulnerabilities within dnsmasq, a package that integrates a caching DNS resolver, a DHCP server, IPv6 router advertisement services, and network boot mechanisms. These lapses facilitate remote code execution with root privileges, the spoofing of IP addresses for specific domains, the exfiltration of process memory fragments, or the precipitous collapse of the service itself. The developers have remediated these issues in version 2.92rel2, with discrete patches made available for integration into existing builds.

    The most critical defect, designated CVE-2026-4892, involves the processing of DHCPv6 requests. It affords a local adversary the opportunity to execute code with root authority via a meticulously crafted packet. The root cause lies in the recording of the DHCPv6 CLID into a buffer without accounting for hexadecimal representation, wherein each physical byte expands into a three-byte sequence of the form “%xx”.

    CVE-2026-2291 pertains to the extract_name() function and may assist a malicious actor in injecting fraudulent records into the DNS cache. Such a scenario paves the way for redirecting a domain to a rogue IP address. This error arose from calculating buffer dimensions without considering the escaping of specific characters within the internal domain name format.

    Furthermore, CVE-2026-4893 involves the handling of DNS packets containing client subnet data per RFC 7871. Due to deficient verification, the source of a response could be erroneously deemed valid, creating the conditions to manipulate the DNS response path and steer users toward an attacker-controlled resource.

    The remaining vulnerabilities impact DNSSEC validation and DNS response handling. CVE-2026-4891 leads to an out-of-bounds read, potentially disclosing memory fragments in response to a malformed DNS query. CVE-2026-4890 triggers an infinite loop during DNSSEC verification, facilitating a Denial-of-Service (DoS) attack, while CVE-2026-5172, linked to the extract_addresses() function, can cause the service to terminate unexpectedly when processing malicious DNS responses.

    Dnsmasq is an integral component of Android, OpenWrt, DD-WRT, and the firmware of myriad wireless routers and Linux distributions. On workstations and servers, it frequently appears alongside libvirt to provide DNS services for virtual machines or is invoked via NetworkManager. The status of these critical patches is currently being monitored by maintainers of Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch, Fedora, OpenWRT, and FreeBSD.

  • GhostLock: The No-Encryption “Ransomware” That Can Paralyze Windows File Servers in Minutes

    A security researcher has demonstrated an unconventional method to paralyze Windows file servers without resorting to data encryption or malicious drivers. This exploit relies solely on the native CreateFileW function—a fundamental utility employed daily by ubiquitous applications such as Microsoft Word.

    This nascent technique, christened GhostLock, was pioneered by Kim Dvash of Israel Aerospace Industries. The methodology exploits a standard Windows mechanism governing file access; by opening a file in a so-called exclusive mode, the operating system summarily prohibits access to all other users and applications until the connection is severed.

    The attack is efficacious against both local file systems and SMB network shares. An adversary can execute GhostLock under the guise of an ordinary domain user without elevated privileges. The tool recursively traverses directories, systematically opening files in exclusive access mode. Once these assets are seized, any subsequent attempt to access the documents results in a STATUS_SHARING_VIOLATION error.

    According to the architect of GhostLock, the mechanism functions less like conventional ransomware and more like a Denial-of-Service (DoS) assault. While the data remains unencrypted and intact, the enterprise effectively loses dominion over its operational files. Business applications falter, resource management systems grind to a halt, and employees are rendered unable to access critical documentation.

    The researcher notes that Windows maintains locking information exclusively within the kernel memory, leaving the physical disk untainted. Upon the termination of the SMB session, a system reboot, or the cessation of the process, access to the files is automatically restored.

    GhostLock poses a particularly grave threat to expansive networks. Utilizing 32 concurrent threads, the tool is capable of sequestering hundreds of thousands of files in under ten minutes. Its creator asserts that on a 10 GbE network, an assault on a repository containing 500,000 files completes with greater celerity than many ransomware strains, yet without the telltale signatures of mass data modification or encryption.

    A further complication arises from the attack’s inherent stealth. Most defensive systems are calibrated to detect anomalies such as mass file renaming or a surge in data entropy; however, GhostLock merely issues legitimate file-opening requests. From a network traffic perspective, the activity mirrors the benign operations of standard office software.

    Kim Dvash warns that malicious actors may employ GhostLock as a diversionary tactic during a breach. While the IT department is preoccupied with resolving file unavailability, attackers can proceed to exfiltrate data or navigate laterally through the network.

    The project’s author has published GhostLock on GitHub, accompanied by a detailed methodology, traffic analysis detection rules, and SIEM queries. The specialist maintains that the only reliable way to identify such an attack is by monitoring for an exorbitant volume of files opened with ShareAccess = 0 on the file server—a metric that most corporate monitoring systems currently neglect to collect.

  • Checkmarx Fails Again: TeamPCP Hijacks Jenkins Plugin to Harvest Developer Credentials

    Unidentified adversaries have subverted the Checkmarx plugin for Jenkins, embedding deleterious code designed for credential exfiltration. This incursion represents the latest installment in a persistent series of software supply chain attacks orchestrated by the collective known as TeamPCP.

    Jenkins is utilized by thousands of enterprises to automate the compilation, testing, and deployment of software. The Checkmarx AST plugin facilitates the integration of security audits within these automated pipelines. Over the past weekend, Checkmarx issued a formal alert indicating that a modified, compromised version of the plugin had surfaced within the Jenkins Marketplace.

    The corporation announced that it is currently engineering a remediated, secure iteration. The counterfeit release, designated as version 2026.5.09, was uploaded to the repo.jenkins-ci.org repository on May 9, circumventing official publication protocols. Analysts noted that the versioning deviated from established nomenclature and lacked a corresponding GitHub tag or release documentation.

    TeamPCP has claimed responsibility for the breach. The group was previously implicated in the Shai-Hulud NPM attacks and the compromise of the Trivy vulnerability scanner. According to offensive security engineer Adnan Khan, the adversaries gained unauthorized access to Checkmarx’s GitHub repositories to inject the credential-harvesting payload.

    A Checkmarx spokesperson confirmed that the perpetrators secured access to the repositories following the initial assault on Trivy in March. The hackers left a mocking missive within the repository description: “Checkmarx fails to rotate secrets again. With love – TeamPCP.”

    Leveraging stolen credentials, TeamPCP disseminated infected versions of various developer tools across GitHub, Docker, and VSCode. The malware systematically gathered intelligence from programmer development environments. Reports suggest the group maintained persistence for at least a month, during which they successfully deployed a tainted version of the KICS tool on Docker, Open VSX, and VSCode.

    Previously, in late April, Checkmarx reported that the LAPSUS$ collective had leaked data exfiltrated from its private GitHub repositories.

    The company advises Jenkins administrators to verify that they are utilizing version 2.0.13-829.vc72453fa_1c16, dated December 17, 2025, or an earlier legitimate release. While precise technical details of the malicious plugin’s operation remain undisclosed, Checkmarx recommends that all access secrets be considered compromised. Users should rotate credentials immediately and scrutinize their infrastructure for signs of persistence or lateral movement.

    Checkmarx clarified that its GitHub repositories remain isolated from customer production environments and that no user data was harbored within the breached repositories. The firm has published indicators of compromise (IoCs) to assist administrators in auditing their systems for traces of the offensive.

  • The Kernel Kill Switch: Sasha Levin’s New “Last Line of Defense” for Linux Vulnerability Mitigation

    Administrators of expansive Linux fleets are being presented with an emergency “kill switch” designed to neutralize vulnerable segments of the kernel. Kernel maintainer Sasha Levin has submitted a patch titled Killswitch to the mailing lists, a mechanism that enables an administrator to temporarily compel a specific kernel function to immediately return a predefined value without executing its internal logic. This concept is specifically engineered for the critical window between the public disclosure of a vulnerability and the moment a remediated kernel is compiled, deployed, and initialized following a system reboot.

    The mechanics are rudimentary yet remarkably transparent. A privileged administrator issues a command to /sys/kernel/security/killswitch/control—targeting, for instance, af_alg_sendmsg. Once activated, the designated function returns -EPERM upon every invocation, effectively bypassing the function body. This mitigation takes effect instantaneously and persists until the next reboot, by which time a permanent kernel patch should ideally be implemented.

    Levin elucidates that the inspiration for this design stems from the logistical tribulations of managing large-scale infrastructures. A kernel vulnerability may attain ubiquity within hours, whereas updating an entire server farm frequently demands a more protracted timeframe. Furthermore, many nascent vulnerabilities manifest within subsystems that are non-essential for all deployments, such as AF_ALG, ksmbd, nf_tables, vsock, or ax25. For the majority of environments, the temporary loss of a specific socket family or subsystem is a far more palatable alternative than operating on an indisputably compromised kernel.

    Importantly, Killswitch is neither a replacement for livepatch nor a method for introducing a corrected function implementation. The patch simply establishes an intercept via kprobe, writes the desired return value into the appropriate register, and circumvents the function’s execution. The documentation explicitly states that the mechanism does not validate the return value type nor does it maintain a whitelist of permissible functions; if the kprobe layer accepts the symbol, Killswitch will attempt the interception. Consequently, the onus of selecting the correct function and return value rests entirely upon the administrator.

    Developers have articulated the primary risk associated with this tool: one must not indiscriminately disable a function merely because a vulnerability exists in its vicinity. If a function is responsible for preparing data, acquiring references, or populating page lists, bypassing its body may destabilize the calling code more profoundly than the original vulnerability itself. The prescribed approach involves selecting a high-level entry point, such as a system call handler, where an error response—indicating “operation failed”—is gracefully returned to user space.

    The patch also introduces diagnostic artifacts to the system. Upon the inaugural activation of Killswitch, the kernel is assigned a new taint flag (designated by the letter ‘H’), alerting developers during crash analysis that the operational kernel image has diverged from its source code. Every disabled function is accompanied by call counters, and all activation or deactivation events are logged alongside operator metadata. Should a module containing an intercepted function be unloaded, Killswitch automatically relinquishes the intercept and issues a warning.

    Levin published the initial version of the patch on May 7, followed by a second revision on May 8. In v2, the developer integrated a LOCKDOWN_KILLSWITCH mode, refined reference counting, and documented the rationale for utilizing atomic_long_t for return values. With the modification spanning 21 files and comprising 1,513 lines of code, this represents a substantial new administrative capability rather than a minor adjustment.

    While Killswitch remains a proposal under deliberation, it offers a “last line of defense” for Linux administrators: rather than attempting to repair vulnerable code in real-time, one may temporarily excise a hazardous execution path until a standard update can be performed. The trade-offs are manifest: certain functionalities may be rendered inoperable, and an erroneous choice of interception point could transform a temporary safeguard into a novel source of systemic failure.

  • Trellix Investigates Unauthorized Breach of Internal Source Code Repository

    Trellix, a preeminent titan in the cybersecurity industry, has disclosed a breach of its internal source code repository. For a corporation whose offerings are engineered to safeguard enterprise networks and endpoints, even a peripheral unauthorized access to its codebase represents an incident of grave magnitude.

    The firm confirmed the incursion via a formal communique on its official portal. Upon identifying the intrusion, Trellix enlisted independent digital forensics experts to spearhead a comprehensive inquiry while concurrently apprising law enforcement agencies of the breach.

    The adversaries gained ingress to a segment of Trellix’s internal repository. Such repositories are frequently coveted by malicious actors with greater fervor than standard corporate data; through the source code, they may identify latent vulnerabilities, orchestrate supply chain offensives, attempt the insertion of backdoors, or gain a profound understanding of the internal architecture of defensive solutions.

    According to preliminary investigative findings, Trellix has identified no evidence to suggest that the assailants compromised its code distribution or release systems. Furthermore, the company maintains that there is no indication that the exfiltrated source code has been leveraged in active campaigns or that any client-facing products and protective measures have been manipulated.

    Nonetheless, the incident precipitates significant reputational and technical jeopardy. Given Trellix’s pivotal role in endpoint protection and Extended Detection and Response (XDR), access to its internal logic provides adversaries with material for subsequent forensic analysis, even in the absence of immediate demonstrable harm to its clientele.

    This transgression mirrors analogous assaults on major technological and cybersecurity entities, including Microsoft, Okta, and LastPass. Trellix has pledged to furnish the community with further technical specifications upon the culmination of its investigation.

  • Wireshark Remediates 40+ Flaws to Block Remote Code Execution via Malicious Packets

    Wireshark has undergone a monumental security refinement, with developers remediating over forty vulnerabilities. A subset of these defects potentially facilitates remote code execution (RCE) through meticulously engineered network packets or malicious capture files. For a utility indispensable to traffic analysis and forensic investigations, such risks are particularly acute.

    The security mandate arrived with the release of version 4.6.5. Developers urge an immediate transition to this iteration for all practitioners operating within corporate infrastructures, Security Operations Centers (SOCs), or research laboratories.

    The most perilous flaws reside within components responsible for dissecting network protocols and telemetry:

    • The TLS module (CVE-2026-5402) suffers from a failure state during the parsing of malformed traffic, potentially precipitating code execution.
    • The SBC audio codec handler (CVE-2026-5403) exhibits a synonymous vulnerability during data analysis.
    • The RDP module (CVE-2026-5405) is susceptible during the deconstruction of Remote Desktop Protocol packets.
    • The Profile Import mechanism (CVE-2026-5656) may permit code execution upon the loading of compromised configurations.

    In each instance, the incursion typically originates with a system crash; however, under optimal conditions, an adversary may seize total control. The gravity of the situation is compounded by a common administrative habit: in enterprise settings, Wireshark is frequently executed with elevated privileges, meaning a successful exploit grants the interloper expansive authority over the host machine.

    A substantial portion of the remaining remediations addresses Denial of Service (DoS) vectors. Diverse dissector modules are prone to failure when processing specially crafted packets, affecting a plethora of protocols—from Monero, BT-DHT, and ICMPv6 to HTTP, WebSocket, and MySQL. An unauthenticated assailant residing on the same network can trigger these failures without prior authorization.

    Furthermore, a specific category of defects causes the application to hang. Certain errors induce infinite loops that paralyze analysis and exhaust system resources, impacting components such as SMB2, TLS, OpenFlow, and USB HID. In automated packet capture systems, a single such discrepancy can halt the entire diagnostic pipeline, rendering Wireshark incapable of processing nascent data.

    The developers have also addressed profound vulnerabilities within the decompression engines. Errors in the handling of zlib compressed data and the LZ77 algorithm resulted in system crashes during packet dissection. These structural defects are more insidious than protocol-specific flaws; any protocol utilizing compression becomes a potential vector, significantly expanding the attack surface.

    The comprehensive remediation effort spans several categories: code execution in TLS, RDP, and SBC modules; systemic freezes during protocol dissection; widespread crashes; and flaws within the decompression logic. The spectrum of CVE identifiers encompasses dozens of entries, ranging from CVE-2026-5299 to CVE-2026-6870.

    The Wireshark team noted that a segment of these vulnerabilities was unearthed utilizing AI-augmented diagnostic tools, which accelerated the verification of numerous protocol modules and facilitated the identification of issues across disparate sections of the codebase. For organizations where Wireshark is integrated into monitoring systems or SIEM infrastructures, this update is a paramount priority. Flaws in TLS, RDP, and SBC offer attackers a portal for code execution, while hangs and crashes allow for the neutralization of network analysis with a solitary packet.

  • The “Unpatchable” Ghost: How PhantomRPC Turns Windows Architecture Against Itself for SYSTEM Control

    Security researchers at Kaspersky Lab have identified a surreptitious methodology within Windows to obtain absolute systemic hegemony—a vulnerability for which a remediation remains notably absent. By merely impersonating a specific system service, an adversary can compel the machine to relinquish SYSTEM-level privileges autonomously.

    The flaw resides within the Remote Procedure Call (RPC) mechanism, the quintessential architecture in Windows responsible for inter-process communication. Through this framework, applications and services invoke functions across disparate contexts. This labyrinthine system has a long-standing reputation as a prolific source of security complications.

    The nascent research delineates a structural vulnerability within this architecture. The exploit facilitates Privilege Escalation to the highest tier, provided the process possesses the requisite “impersonation” rights. Such permissions are inherently granted to various service accounts, including network services. Despite Microsoft being formally apprised of the flaw, the corporation has refrained from issuing a patch, designating the risk as merely “moderate.”

    The essence of the assault is deceptively elegant. Within Windows, numerous services commune via RPC; should a requisite service be dormant, the system nonetheless attempts a connection, culminating in an error. At this precise juncture, an interloper can introduce a fraudulent server utilizing the identical interface to “intercept” the request.

    Subsequently, a specific nuance of the impersonation mechanism is triggered: a server may temporarily adopt the security context of the client that initiated the connection. Should that client be a system service or an administrative entity, the adversary inherits those exact credentials.

    One illustrative scenario involves the Group Policy service. During configuration updates, it endeavors to communicate with the Remote Desktop Service. If the latter is deactivated, the request is susceptible to interception. The fraudulent server accepts the connection and “assumes” SYSTEM-level authority. Consequently, the adversary elevates their stature from a mere network service to the zenith of systemic control.

    An analogous stratagem operates without direct coercion. For instance, the Microsoft Edge browser initiates such a request upon launch; an adversary need only wait for an administrator to open the browser for the malicious server to procure their rights. Furthermore, entirely automated variants exist: certain background system services periodically attempt to contact the Remote Desktop Service. In this instance, the aggressor simply awaits the inevitable moment the system surrenders the coveted request.

    Another manifestation targets the DHCP client. By disabling the corresponding service and substituting its interface, the execution of a standard ipconfig command causes administrative rights to migrate to the adversary. Similar logic applies to the Windows Time service, where the utility initially attempts to connect to a non-existent channel that can be readily occupied.

    The predicament is more profound than it initially appears. Windows fails to verify the authenticity of the RPC server accepting the request; any process can instantiate a service with the requisite nomenclature and interface. Given the ubiquity of RPC within the operating system, the potential attack surface is vast.

    To identify these vulnerabilities, specialists scrutinized system logs to track unsuccessful RPC inquiries. Of particular interest are instances where a high-privilege process attempts to interface with a non-existent service that permits impersonation. Each such failure represents a potential portal for ingress.

    A comprehensive resolution is impossible without a fundamental architectural overhaul. Currently, mitigation is limited to risk reduction: for example, activating dormant services to eliminate “vacant” connection points and restricting the dissemination of impersonation rights among unnecessary processes. The vulnerability was verified on Windows Server 2022 and Windows Server 2025 with the latest security updates, though the underlying architecture suggests it plagues other iterations of Windows as well.

  • The Critical 9.1 Flaw in ASP.NET Core that Turns Cookies into Master Keys

    An unforeseen regression within a software update has inadvertently caused a security mechanism to serve as a gateway for adversaries. In a decisive response, Microsoft has disseminated emergency remediations to rectify a formidable vulnerability within the ASP.NET Core framework.

    The flaw, designated as CVE-2026-40372 and carrying a critical CVSS score of 9.1, resided within the Data Protection cryptographic interfaces. This vulnerability empowered unauthenticated attackers to elevate their privileges to SYSTEM level by merely forging authentication cookies and circumventing identity verification protocols.

    The malfunction surfaced amidst a wave of user grievances; following the deployment of the .NET 10.0.6 update, applications began to falter during data decryption. Forensic analysis traced the root cause to a regression in Microsoft.AspNetCore.DataProtection (versions 10.0.0 through 10.0.6). The integrity verification mechanism was erroneously calculating signatures based on invalid telemetry or, in certain instances, disregarding the verification results entirely.

    Consequently, the defensive perimeter mistakenly validated fraudulent data as legitimate. An assailant could not only exfiltrate previously shielded information—such as session cookies, anti-forgery tokens, or authorization parameters—but also fabricate entirely new entries. By successfully impersonating a privileged entity, the adversary could compel the system to generate authentic tokens, including access keys, password reset links, or session refreshers. Crucially, these tokens may remain functional even post-remediation unless the underlying encryption keys are rotated. While the vulnerability facilitates unauthorized data modification and file access, it does not compromise systemic availability.

    Microsoft urgently advocates for the immediate elevation of the Microsoft.AspNetCore.DataProtection package to version 10.0.7 and the subsequent redeployment of affected applications. Upon updating, the system will autonomously reject any forged payloads. Furthermore, it is prudent to rotate master security keys to invalidate any clandestine tokens that may have been generated prior to the fix.