Attacks on open-source mostly start with publishing new malicious packages in repositories. But the attack that occurred on March 14 is in a different league — attackers compromised the popular GitHub Action tj-actions/changed-files, which is used in more than 23,000 repositories. The incident was assigned CVE-2025-30066.  All repositories that used the infected changed-files Action are susceptible to this vulnerability. Although the GitHub administration blocked changed-files Action and then rolled it back to a safe version, everyone who used it should conduct an incident response, and the developer community should draw more general lessons from this incident.

What are GitHub Actions?

GitHub Actions are workflow patterns that simplify software development by automating common DevOps tasks. They can be triggered when certain events (such as commits) occur at GitHub. GitHub has a kind of app-store where developers can take a ready-made workflow process and apply it to their repository. To integrate such a ready-made GitHub process into your CI/CD development pipeline, you only need one line of code.

changed-files compromise incident

On March 14, the popular tj-actions/changed-files GitHub Action — used to get any changed files from a project — was infected with malicious code. The attackers modified the process code and updated the version tags to include a malicious commit in all versions of changed-files GitHub Action. This was done on behalf of the Renovate Bot user, but according to current information the bot itself wasn’t compromised; it was just a disguise for an anonymous commit.

The malicious code in changed-files is disguised as the updateFeatures function, which actually runs a malicious Python script and dumps the Runner Worker process memory, then searches it for data that looks like secrets (AWS, Azure and GCP keys, GitHub PAT and NPM tokens, DB accounts, RSA private keys). If something similar is found, it’s written to the repository logs. Both the malicious code and the stolen secrets are written with simple obfuscation — double base64 encoding. If the logs are publicly available, attackers (and not only the operators of the attack, but anyone!) can freely download and decrypt this data. On March 15, a day after the incident was discovered, GitHub deleted the changed-files process, and the CI/CD processes based on it may have not functioned. After another eight hours, the process repository was restored in a “clean version”, and now changed-files is working again without surprises.

Incident Response

Since logs in public repositories are accessible to outsiders, they’re the most likely to have been affected by the leak. However, in an enterprise environment, relying solely on the assumption that “all our repositories are private” is also not a good idea. Companies often have both public and private repositories, and if their CI/CD pipelines use overlapping secrets, attackers can still use this data to compromise container registries or other resources. Containers or packages built by popular open-source projects can also be compromised in this scenario.

The authors of the ill-fated changed-files recommend analyzing GitHub logs for March 14 and 15. If unusual data is found in the changed-files subsection, it should be decoded to understand what information may have been leaked. Additionally, it’s worth examining GitHub logs for this period for suspicious IP addresses. All changed-files users are advised to replace secrets that could have been used in the build and leaked during this period. First of all, you should pay attention to repositories with public CI logs, and secondly, to private repositories.

In addition to replacing potentially compromised secrets, it’s recommended to download the logs for subsequent analysis, and then clear their public versions.

Lessons from the incident

The complexity and variety of attacks on the supply chain in software development are growing: we’ve already become accustomed to attacks in the form of malicious repositories, infected packages and container images, and we’ve encountered malicious code in test cases — and now in CI/CD processes. Strict information-security hygiene requirements should extend to the entire life-cycle of an IT project.

In addition to the requirement to strictly select the source code base of your project (open source packages, container images, automation tools), a comprehensive container security solution and a secrets management system are necessary. Importantly, the requirements for special handling of secrets apply not only to the project’s source code, but also to the development processes. GitHub has a detailed guide on securely configuring GitHub Actions — the largest section of which is devoted specifically to handling secrets.

Kaspersky official blog – ​Read More

Cisco Talos’ Vulnerability Discovery & Research team recently disclosed a Miniaudio and three Adobe vulnerabilities.  

The vulnerabilities mentioned in this blog post have been patched by their respective vendors, all in adherence to Cisco’s third-party vulnerability disclosure policy.    

For Snort coverage that can detect the exploitation of these vulnerabilities, download the latest rule sets from Snort.org, and our latest Vulnerability Advisories are always posted on Talos Intelligence’s website.     

Miniaudio out-of-bounds write vulnerability 

Discovered by Emmanuel Tacheau of Cisco Talos.   

TALOS-2024-2063 (CVE-2024-41147) is an out-of-bounds write vulnerability in Miniaudio, a lightweight, single-file audio playback and capture library written in C. A missing allocation size check can cause a buffer overflow, leading to this out-of-bounds write. This vulnerability can be triggered by a specially crafted FLAC file, resulting in a memory corruption when in playback mode. The application sends raw audio data to Miniaudio, which is then played back through the default playback device as defined by the operating system. 

Adobe Acrobat out-of-bounds write vulnerability 

Discovered by KPC of Cisco Talos.   

TALOS-2025-2134 (CVE-2025-27163) and TALOS-2025-2136 (CVE-2025-27164) are out-of-bounds read vulnerabilities in the font functionality, which can lead to disclosure of sensitive information. TALOS-2025-2135 (CVE-2025-27158) is a memory corruption vulnerability, stemming from an uninitialized pointer in the font functionality of Adobe Acrobat, which can potentially lead to arbitrary code execution. A specially crafted font file embedded into a PDF can trigger these vulnerabilities. An attacker needs to trick the user into opening a malicious file. 

Cisco Talos Blog – ​Read More

On March 4, Broadcom released emergency updates to address three vulnerabilities — CVE-2025-22224, CVE-2025-22225 and CVE-2025-22226 — that affect several VMware products, including ESXi, Workstation, and Fusion. A note in the Broadcom advisory stated that at least one of these — CVE-2025-22224 — has been exploited in real-world attacks. The vulnerabilities allow for virtual machine escape — enabling attackers to execute code directly on the ESX hypervisor. Information available on VMware’s GitHub suggests that the Microsoft Threat Intelligence Center was the first to detect the exploit in the wild and notify Broadcom. Neither company has named the attacker or the victim.

Broadcom reports that the vulnerabilities affect VMware ESXi 7.0–8.0, Workstation 17.x, vSphere 6.5–8, Fusion 13.x, Cloud Foundation 4.5–5.x, Telco Cloud Platform 2.x–5.x, and Telco Cloud Infrastructure 2.x–3.x. However, some experts suggest that the range of impacted products is potentially wider. In particular, older versions of ESXi, such as 5.5, should be vulnerable as well, but these unsupported versions are not getting patched. According to some assessments, more than 41,000 ESXi servers had been affected across the globe (mainly in China, France, the U.S., Germany, Iran and Brazil) as at the end of last week.

What issues VMware has fixed

The most severe vulnerability in VMware ESXi and Workstation — CVE-2025-22224 — received a CVSS rating of 9.3. It’s related to a heap overflow in VMCI, and allows an attacker with local administrative privileges on the virtual machine to execute code as the VMX process on the host — the hypervisor.

The CVE-2025-22225 vulnerability in VMware ESXi (CVSS 8.2) allows an attacker to perform an arbitrary kernel write, which also implies sandbox escape. CVE-2025-22226 — an HGFS information disclosure vulnerability (CVSS 7.1) — permits an attacker with guest VM administrative access to extract the contents of the VMX process memory. VMware ESXi, Workstation, and Fusion are affected by this vulnerability.

Dangerous exploitation scenarios

The vulnerability descriptions indicate that exploitation requires an attacker to have already compromised the virtual machine and possess administrative privileges on it. This seems like a relatively high entry barrier, but in reality such a scenario can materialize quite easily. The primary danger of these vulnerabilities is that they drastically reduce the steps an attacker needs to take from compromising a single virtual machine to completely seizing control of the computing cluster. The trio of vulnerabilities allows the attacker to reach hypervisor level without conducting “noisy” network environment scans for servers, or having to circumvent network security measures. The following are typical enterprise scenarios where this could occur:

• VMware-based VDI workstations. A single employee makes a mistake by launching a malicious attachment on their virtual workstation. Instead of just one workstation being compromised, this leads to a large-scale incident.
• VMware-based hybrid and private clouds. A successful compromise of any server via a publicly accessible application vulnerability allows an attacker to rapidly propagate the attack across the entire network.
• Leasing virtual servers and workstations (prebuilt VMs) from an MSP. A client’s error leading to infection on a rented host will result in compromise of all MSP clients sharing resources within the same cluster.

Some features of VMware clusters create further complexities in detecting and remediating such incidents. Once an attacker compromises the hypervisor level, they automatically gain access to all storage connected to the cluster. The attacker can then move freely throughout the VMware environment, and the configuration files available from the hypervisor permit their conducting extensive reconnaissance without raising security alerts.

The hypervisor lacks an EDR agent, and security tools have very limited visibility into what’s happening at the cluster level. Hackers can sneak in and grab important information, such as Active Directory databases, without security teams noticing. All of these factors make the three VMware vulnerabilities a veritable goldmine for malicious actors — particularly ransomware groups. They’ve repeatedly conducted attacks on ESXi environments in the past: RansomExx, ESXiargs, Clop, and so on.

Recommendations for organizational security

Luckily for businesses, proof-of-concept (PoC) code for exploiting these vulnerabilities has not yet been published, so widespread exploitation of the flaw has not begun. Nevertheless, such code could surface at any moment, so VMware products need to be updated quickly as a top priority. Since patching VMware environments can be complex, especially in high-availability infrastructures, organizations should leverage tools like vMotion to deploy patches without downtime.

Patching is the only mitigation for these vulnerabilities. However, Broadcom also recommends reviewing your settings according to the vSphere Security Configuration & Hardening guide. Among other things, you need to ensure that your VMware infrastructure is properly segmented to restrict access to the hypervisor management network.

Be sure to use cloud security tools, including having an EDR agent properly installed and running on your virtual machines. This will allow for the detection and prevention of the initial infection stage — blocking attackers from obtaining the administrative access required to exploit the vulnerabilities.

Kaspersky official blog – ​Read More

• Cisco Talos has identified actors abusing Cascading Style Sheets (CSS) to 1) evade spam filters and detection engines, and 2) track users’ actions and preferences. 
• This blog is a follow-up to our previous report on how threat actors could abuse CSS using a technique called “hidden text salting” to evade spam filters, email parsers, and detection engines. This technique introduces several security implications. 
• Additionally, we have observed the abuse of CSS for tracking, which impacts users’ privacy. This abuse ranges from tracking users’ actions to identifying their preferences. Although email clients restrict the execution of JavaScript, we argue that fingerprinting system and hardware configurations is also possible using CSS properties and rules, depending on the users’ clients and system configurations.

Cascading Style Sheets (CSS) specify how HTML materials are rendered and displayed to recipients. In a legitimate context, CSS is mainly used to adjust an email’s content to fit the screen resolution of the recipient. However, we will discuss how CSS can be abused by threat actors to stay under the radar and track recipients at a minimum. The features available in CSS allow attackers and spammers to track users’ actions and preferences, even though several features related to dynamic content (e.g., JavaScript) are restricted in email clients compared to web browsers. In what follows, we provide examples of CSS abuse we’ve identified in the wild for both evading detection and tracking users. These examples have all been observed from the second half of 2024 up until February 2025.

The abuse of cascading style sheets for evasion

Features of HTML and CSS can be used together to include comments and irrelevant content that are not visible to the victim (or recipient) when the email is rendered in an email client but can impact the efficacy of parsers and detection engines. We discussed a few examples in our recent blog post, and we will share more throughout the rest of this section. We will not cover cases that are well-known to the security community, such as including zero-sized fonts.

Threat actors can use the text_indent property of CSS to conceal content in the email’s body. Below is an example of a phishing email that contains text in different places, but the text is not visible when rendered in an email client.

An inspection of the HTML source of the above email reveals that hidden text salting has been used in several places. For example, in the snippet shown below, the text-indent and font-size properties of CSS are used together to conceal the gibberish characters added in between the original words visible to the recipient of this email.

The text-indent property is set to –9999px, which moves the text far out of the visible area when the email is rendered in the email client. Additionally, the font-size property is set to an extremely small size, making the text virtually invisible to the human eye on most screens. In some cases, the text color is also set to transparent to ensure the text is completely invisible by rendering it in a color that does not display against any background.

Alternatively, threat actors may use the opacity property of CSS to hide the irrelevant content. An example phishing email is shown below that also impersonates the Blue Cross Blue Shield organization.

A close inspection of the HTML source of the above email reveals multiple attempts to conceal content, both in the body of the email and in the email’s preheader. Most email templates enable threat actors to add preheader text to their emails. Such text follows the email’s main subject immediately and is a technique that allows attackers to entice readers with additional information. Note that this field is also used in many email marketing and spam campaigns.

In this example, the attacker has set the opacity property of CSS to zero, making the element fully transparent and invisible. Note that this preheader text is kept hidden by relying on multiple CSS properties, including color, height, max-height, and max-width. Additionally, the mso-hide property is set to all to make the preheader invisible in Outlook email clients as well. Also, note that the invisible preheader text is completely irrelevant and appears benign (e.g., “FOUR yummy soup recipes just for you!”) to make it appear less suspicious to spam filters.

In a third example, the HTML smuggling technique is used to redirect the user to the final phishing page. This was a spear phishing email sent to one of our customers in February 2025. Additionally, the HTML attachment contains a series of German words and phrases that do not form coherent or grammatically correct sentences, and these are made invisible to the recipient of the email via hidden text salting.

The email contains the phrase “with regard” in two other languages, including Finnish and Estonian. The rendered HTML attachment is also shown below. Note that the attacker tries to convince the recipient to click on the button and view the document by displaying a Microsoft SharePoint logo.

When the HTML attachment of the above email is inspected, one can notice that CSS properties are employed in various ways to conceal the irrelevant German phrases. First, the paragraphs’ positions are set to absolute, allowing them to be placed anywhere on the page, which is often a technique used to hide elements by moving them off-screen. Additionally, the width and height of the paragraphs are set to zero, rendering them invisible in terms of space. The opacity is also set to zero, making the content transparent and unseen by the recipient. Furthermore, a clipping method is utilized to ensure that the added salt remains hidden from the victim. Specifically, the first paragraph is clipped using a rectangle with the clip CSS property (which is deprecated as of this writing) that has zero width and height, effectively making it invisible by limiting its visible area. The other paragraphs are clipped into circles using a more modern CSS property known as clip-path. Lastly, the overflow property is set to hidden, ensuring that any content that exceeds the boundaries of the div element stays concealed.

The abuse of cascading style sheets for tracking

Email clients use different rendering engines and support different CSS rules and properties. However, CSS properties can be abused to track users’ actions and preferences. We will discuss how fingerprinting recipients’ systems and hardware is also possible, although some of these fingerprinting approaches may only work in specific email clients and depend on certain configuration assumptions.  

Marketing campaigns may use these CSS properties to track user engagement and optimize future campaigns, while spammers and threat actors may use this approach to enhance their targeted phishing campaigns, collect information, and craft targeted exploits. In what follows, we provide only a few examples of attempts to compromise the privacy of our customers.

Tracking users’ (or email recipients’) actions and preferences has been one of the most dominant patterns of CSS abuse identified by Talos in the wild in recent months. This abuse can range from identifying recipients’ font and color scheme preferences and client language to even tracking their actions (e.g., viewing or printing emails). Below is an example of a spam email with multiple tracking capabilities.  

The HTML source of the above email is shown below, where several tracking approaches are employed. First, the campaign uses a tracking image to record when the recipient opens the email. Second, different tracking URLs log the recipient’s color scheme preference (see the rd and rl characters in the URLs). This is achievable via the CSS media at-rule. Third, a tracking URL records when this email is printed (see the p character in the URL). Finally, different tracking URLs are used to record when the email is opened in a specific email client. Also, note that a unique identifier is assigned to each recipient and used in the tracking URL.

A second example email is shown below that tracks even more information, including the recipient’s geo-location and device-specific information.

An inspection of the HTML source of the above message, shown below, reveals several tracking clues. First, a tracking image is used to record when the recipient opens the email. Second, the recipient’s color scheme preference is tracked via separate URLs. Third, a tracking URL is embedded within this message that records when it is printed. Fourth, different tracking URLs are used to record when the email is opened in a specific email client. Finally, a tracking pixel is appended to the end of the email to collect the recipient’s IP address, the email client used to open the email, and some device-specific information.

As explained earlier, CSS provides a wide range of rules and properties that can help spammers and threat actors fingerprint users, their webmail or email client, and their system. For example, the media at-rule can detect certain attributes of a user’s environment, including screen size, resolution, and color depth. The HTML code snippet below demonstrates how the CSS media at-rule can be used for such purposes. Threat actors can set up different styles or load different resources based on criteria such as the screen width of the recipient’s device.

Fingerprinting the operating system of the recipient’s device is also possible and can be done in at least two main ways. In the first approach, the availability of certain fonts on a recipient’s system can indicate which operating system they might be using. Furthermore, threat actors may block the display of certain elements based on the inferred operating system. This can be achieved via the font-face at-rule in CSS.

In the example shown below, the body of the message uses the Segoe UI font, which is commonly available on Windows operating systems by default. Additionally, the font-face at-rule defines a font called MacFont, which relies on the local availability of Helvetica Neue. This font is typically found on macOS systems. Note that in this example, elements with the class .mac-style are hidden by default (display: none;). They are only shown to the recipient (display: block;) if the hypothetical media rule detects MacFont.

The second method that can be used to fingerprint the operating system of a recipient’s device is to use unique URLs for resources (e.g., images) based on the applicable styles. When the email loads these resources, server logs can provide hints about the recipient’s operating system. In the example snippet shown below, different images are loaded depending on the victim’s operating system, which can be determined by the availability of certain fonts and styles that were applied.

Mitigations

As explained with multiple examples, CSS provides functionalities, rules, and properties that could be abused by attackers to evade spam filters and detection engines, as well as to track or fingerprint users and their devices. As such, both the security and privacy of your organization and business are at risk. In what follows, we provide a few mitigation solutions for each domain.

Security mitigations: One security mitigation solution is to rely on advanced filtering mechanisms that can more effectively detect hidden text salting and content concealment. These systems could examine different parts of emails to find and filter out hidden content. Alternatively, relying on features in addition to the text domain, such as the visual characteristics of emails, could be helpful. This approach is particularly beneficial in image-based threats.

Privacy mitigations: One of the most effective solutions in this domain is to use email privacy proxies. This mitigation is designed for email clients and involves rewriting emails to enhance privacy and maintain email integrity across different clients. In particular, the proxy service should be able to perform two main functions: 1) converting top-level CSS rules into style attributes, and 2) rewriting remote resources (e.g., images) to be included directly in the email via data URLs. The former function confines styles to the email itself and prevents conflicts with client-defined styles, while the latter function prevents exfiltration of information and undermines tracking pixels, ensuring the email’s integrity over time.

Protection

Safeguarding against these complex threats necessitates a comprehensive email security solution that utilizes AI-driven detection. Secure Email Threat Defense employs distinctive deep learning and machine learning models, incorporating Natural Language Processing, within its sophisticated threat detection systems.

Secure Email Threat Defense detects harmful techniques employed in attacks against your organization, extracts unmatched context for particular business risks, offers searchable threat data, and classifies threats to identify which sectors of your organization are most at risk of attack.

Begin strengthening your environment against sophisticated threats. Register now for a free trial of Email Threat Defense.

Cisco Talos Blog – ​Read More

In its monthly Patch Tuesday update, Microsoft has provided patches for six vulnerabilities that are being actively exploited in the wild. Four of these vulnerabilities are related to file systems — three of which having the same trigger, which may indicate that they’re being used in one and the same attack, or at least by the same actor. The details of their exploitation are still publicly undisclosed (fortunately), but the latest update is highly recommended for immediate installation.

File system vulnerabilities

Two of the vulnerabilities were found in the NTFS system. They allow attackers to gain access to parts of the heap — that is, to dynamically allocated application memory. Interestingly, the first of them, CVE-2025-24984 (4.6 on the CVSS scale), implies physical access of the attacker to the victim’s computer (they need to insert a malicious drive into the USB slot). To exploit the second information disclosure vulnerability, CVE-2025-24991 (CVSS 5.5), attackers need to somehow force a local user to mount a malicious virtual hard disk (VHD).

The other two file system vulnerabilities — CVE-2025-24985 in the Fast FAT file system driver, and CVE-2025-24993 in NTFS — are triggered in the same way by mounting a VHD prepared by the attackers. However, their exploitation leads to remote execution of arbitrary code on the attacked machine (RCE). Both vulnerabilities have a CVSS rating of 7.8.

Other exploited vulnerabilities

The CVE-2025-24983 (CVSS 7.0) vulnerability was found in the Windows Win32 kernel subsystem. It can allow attackers to elevate their privileges to the system level. To exploit it, attackers need to win the race condition.

The latest vulnerability from the list of actively exploited ones, CVE-2025-26633 (also CVSS 7.0), allows bypassing the security mechanisms of the Microsoft Management Console. The description provides two scenarios for its exploitation; however, both are related to the delivery of a malicious file to the victim, which must then be run. The first scenario involves delivering the file in an email attachment; the second — delivering a link through an instant messaging program, or, again, via email. According to information from the Zero Day Initiative researchers, who brought this vulnerability to Microsoft’s attention, it’s used by the EncryptHub ransomware group, also known as Larva-208.

And another zero-day vulnerability

In addition to the six vulnerabilities used in active attacks, the update from Microsoft also closes CVE-2025-26630 in Microsoft Access, which has not yet been used by attackers — though it could well be since, according to Microsoft, it’s been publicly known of for some time. This vulnerability has a CVSS rating of 7.8, and its exploitation leads to the execution of arbitrary code. However, the description emphasizes that to exploit it it needs to be opened on the attacked machine, and the Preview Pane is not an attack vector.

Other vulnerabilities

The note about the preview mechanism in the description of CVE-2025-26630 is not accidental — the update also contains a patch for the RCE vulnerability CVE-2025-24057, which is quite exploitable through the Preview Pane. In addition, Microsoft closed more vulnerabilities classified as critical, but not yet exploited. All of them also allow remote arbitrary code execution:

• CVE-2025-24035 and CVE-2025-24045 in the Remote Desktop Service (RDS);
• CVE-2025-24057 in Microsoft Office;
• CVE-2025-24084 in the Windows Subsystem for Linux — a feature of Microsoft Windows that allows the use of a Linux environment from within Windows;
• CVE-2025-26645 in the Remote Desktop client. This vulnerability is exploited when the victim connects to a malicious RDP server.

We recommend installing updates from Microsoft as soon as possible. Since actively exploited vulnerabilities are most likely used by attackers in fairly complex targeted attacks, we also recommend that companies use modern security solutions with EDR functionality, and, if necessary, involve third-party experts to protect themselves; for example, as part of our Managed Detection and Response service.

Kaspersky official blog – ​Read More