In git we trust: Defending Lovable projects from malicious code attacks at scale

In git we trust: Defending Lovable projects from malicious code attacks at scale

Speakers: Marcus (Lovable); Samuel (Security Engineer, Lovable)

Conference: fwd:cloudsec

YouTube: https://www.youtube.com/watch?v=7WdSOGJ7qjk

Overview

This talk, "In git we trust: Defending Lovable projects from malicious code attacks at scale," delivered by Samuel, a Security Engineer, and Marcus from Lovable, delves into a sophisticated, large-scale malicious code injection campaign targeting users of the Lovable platform. Lovable, which empowers over 600,000 customers to create more than 58 million full-stack web applications using an AI agent, faced a persistent threat actor employing advanced social engineering and novel technical obfuscation techniques to compromise user projects.

The speakers meticulously detail how a nation-state-level adversary, using a multi-stage loader malware, leveraged legitimate project configuration files and even the immutability of blockchains for command-and-control (C2) infrastructure. This article unpacks the technical intricacies of the attack, Lovable's comprehensive response, and the broader defensive implications for platforms dealing with user-generated code and the challenges of distinguishing legitimate development from malicious activity at scale. The talk emphasizes that the Lovable platform itself was not compromised, but rather its users were targeted through social engineering.

The significance of this presentation lies in its detailed exposure of a real-world, high-stakes attack that blends social engineering with cutting-edge technical evasion. It highlights the evolving landscape of software supply chain attacks, where adversaries exploit trust relationships and common development workflows. For security professionals, the insights into obfuscation, C2 via blockchain, and large-scale threat hunting provide invaluable lessons in designing resilient systems and proactive defense strategies against highly motivated and well-resourced attackers.

Background

▶ Watch: Introduction to Lovable's AI-powered project platform (0:40)

Lovable operates as a platform designed to simplify the creation and deployment of full-stack web applications. Users interact with an AI agent, providing prompts to generate initial application versions, which can then be iteratively refined and deployed, encompassing front-end, back-end, database, and authentication components. This model, while empowering rapid development, also introduces unique security challenges, particularly when external entities gain access to user projects.

The genesis of this investigation began in March 2025, when a runtime sensor agent on the Lovable platform detected a string of malware within a user's project. This initial alert triggered an in-depth inquiry to determine if it was an isolated experiment or part of a larger, more coordinated effort. The investigation quickly revealed a pattern: a Lovable user had been approached by an individual posing as a legitimate developer, offering assistance to enhance their project. This individual, later identified as a malicious actor, gained access to the user's Lovable project and associated GitHub repository.

Once access was established, the attacker began experimenting with code injection. A critical observation was the attacker's ability to "race" Lovable's AI agent. When a user requested a change via the agent (e.g., updating a WhatsApp link), the agent would commit the change. Mere seconds later, the attacker, with GitHub repository access, would perform a commit with an identical title, injecting malicious code into the project without the user's knowledge. This deceptive tactic made it appear as though the malicious code was part of the agent's legitimate activity. Furthermore, the attackers displayed remarkable audacity, actively engaging with compromised users, denying any wrongdoing, and even attempting to shift blame to Lovable for supposed "vulnerabilities." This level of engagement and deception underscored the sophisticated nature and high motivation of the threat actors involved.

Key Findings

▶ Watch: Attack vector: Malicious 'developer' social engineering (3:30)

The comprehensive investigation initiated by Lovable after the initial detection uncovered a widespread and deeply entrenched campaign. The most significant findings include:

• Scale of Compromise: Lovable identified over 400 projects that had been compromised as part of this campaign. This was discovered through an extensive retroactive analysis involving the scanning of more than 7 million Lovable projects, encompassing an astounding 100 billion lines of code.
• Campaign Longevity and Evolution: The campaign was first encountered in March 2025 and had been actively evolving over the course of the year. This indicates a persistent and adaptable adversary who continuously refined their techniques to bypass detections. Over 200 distinct versions of the malware were observed across various projects and repositories, each with unique campaign tags for tracking.
• Sophisticated Social Engineering: The primary initial vector for compromise was social engineering. Attackers posed as helpful developers to gain access to user projects and their associated GitHub repositories. They also explored other vectors, such as exploiting Lovable's "remix" feature, though this did not become a major avenue for attack. In some cases, suspected compromised end-user credentials were used, where legitimate users suddenly injected malware into their own long-standing projects.
• Platform Integrity: Crucially, the Lovable platform itself was never compromised. The attackers exploited vulnerabilities in human trust and external access mechanisms (like GitHub repository access) rather than directly breaching Lovable's infrastructure.
• Novel C2 Infrastructure: A groundbreaking discovery was the use of blockchains as a command-and-control (C2) mechanism. Malicious payloads were embedded within transaction input fields on public, immutable blockchains, making them extremely resilient to takedown efforts and difficult to trace by conventional means. This represents a significant advancement in attacker evasion techniques.
• Evasive Malware Design: The malware employed highly sophisticated obfuscation techniques to evade signature-based detections. This included multi-stage loaders, custom string decoders using seeded deterministic shuffles, and dynamic construction of JavaScript functions without using explicit function or constructor keywords in the source code. The ability to generate completely unique hashes by subtly altering a seed value made traditional hash-based detection ineffective.

These findings painted a clear picture of a highly resourced, motivated, and technically proficient adversary capable of operating at scale and adapting to defensive measures.

Technical Deep Dive

▶ Watch: Deceptive commit: Malware injection into project (5:10)

The malicious code injection campaign targeting Lovable users showcased an impressive array of technical sophistication, primarily focused on obfuscation, evasion, and novel command-and-control (C2) mechanisms.

The core of the attack involved a loader malware written in obfuscated JavaScript. This malware was strategically injected into common JavaScript configuration files such as PostCSS and Tailwind CSS configurations, which are routinely loaded during the application build process. While PostCSS was the initial primary vector, the attackers quickly diversified, utilizing at least five other common JavaScript config files, demonstrating their adaptability.

Upon execution, the loader malware operates in several distinct stages:

1. Campaign Tag and String Decoding: Each instance of the malware included a unique campaign tag, serving as a version identifier. The first technical hurdle for analysis was a sophisticated string decoder. This decoder utilized a seeded shuffle function, specifically a Fisher-Yates deterministic shuffle, to "unshuffle" an obfuscated payload string back into executable JavaScript. The payload was split into arrays, shuffled, and then hex codes were replaced based on indexes to reconstruct the original code.
2. Global Namespace Aliasing: To further evade detection, the malware immediately aliased critical global functions like require and module. This allowed it to import arbitrary JavaScript modules without explicitly using these keywords, which are often flagged in static analysis for malicious intent.
3. Function Constructor Obfuscation: A particularly clever technique involved the dynamic construction of JavaScript functions. Instead of directly using function or constructor keywords, which are typical indicators of dynamic code execution, the malware built another shuffle function. Within this function's large payload, it extracted a substring that represented the shuffled version of "constructor." This allowed it to invoke the Function constructor and execute code without ever having the string "function" or "constructor" present in the source, effectively bypassing many static analysis tools.
4. Three-Step Execution Engine: The execution engine itself was a multi-layered process. First, it decoded the JavaScript. Second, it passed this decoded JavaScript to a function call that returned a callable object. Third, this callable was invoked with a specific pyd blob. The entire process was governed by a deterministic seed, such as 259. By altering this seed number, the attackers could generate completely different payload data and unique hashes with only minor code changes, rendering hash-based detection techniques largely ineffective.

The infection process within Lovable's build environment was critical. When a user's project was built (e.g., using bun install followed by bun rundev or v build), the system would load the compromised configuration files. This initiated the loader's stage one (decode) and stage two (bootstrap) operations.

A truly novel aspect of this attack was the Command and Control (C2) infrastructure. Instead of traditional DNS or IP-based C2 servers, the loader was programmed to reach out to blockchains. Malicious second-stage payloads were embedded as input data within transactions on these public blockchains. Lovable observed at least three different blockchains being utilized. This C2 method offers significant advantages to attackers:

• Immutability: Once a transaction is on a blockchain, it cannot be altered or removed.
• Public Infrastructure: Blockchains are inherently public and globally accessible, eliminating the need for private hosting infrastructure.
• Resilience to Takedown: Traditional takedown efforts (e.g., sinkholing domains, blocking IPs) are ineffective against blockchain-based C2, making it extremely difficult to disrupt.
• Dynamic Updates: Attackers can simply create new transactions with updated payloads, ensuring a continuous supply of fresh malicious code.

Once the second-stage payload was retrieved from the blockchain, it was executed using the sophisticated loader and execution engine. The final step involved using node -e to spawn a child process. Crucially, this child process was then detached from the main build process. This allowed the malicious code to continue running in the background, even after the CI build completed, effectively escaping the immediate sandbox constraints. Because this occurred within the normal build step, the node process had full access to the local Node.js API and file system, as expected for a legitimate build.

In summary, the attack leveraged several key primitives: obfuscated require and module for stealthy imports, dynamic function/constructor creation for execution evasion, social engineering as the initial entry point, and the innovative use of public blockchains for resilient and untraceable payload delivery. This multifaceted approach highlights the advanced capabilities of the threat actor.

Demo / Proof of Concept

▶ Watch: Attacker infrastructure and malware loader overview (6:00)

While the talk did not feature a live demonstration of the attack or a proof-of-concept exploit, the speakers effectively illustrated the core mechanics and artifacts of the malicious campaign through detailed visual aids and explanations.

Marcus presented a screenshot of the Lovable agent's chat interface, clearly showing a user's request for a legitimate project update (e.g., updating a WhatsApp link). Crucially, this screenshot then displayed two successive commit boxes with identical titles. The first represented the agent's legitimate commit, while the second, occurring just two seconds later, was the attacker's commit. This visual directly demonstrated how the attackers "raced" the agent and injected their code stealthily. The screenshot also explicitly showed the injected malware string at the bottom, making the malicious payload visible.

Samuel then provided a deep dive into the actual obfuscated JavaScript loader code. While not a live demo, he walked the audience through snippets and diagrams, explaining the various stages: the campaign tag, the seeded Fisher-Yates deterministic shuffle for string decoding, the aliasing of require and module, and the complex function/constructor obfuscation techniques. This detailed technical walkthrough served as a "proof of understanding" for the audience, demonstrating the intricate design of the malware.

Furthermore, a pcap file (packet capture) was presented as evidence, illustrating the network traffic generated by the malware. This pcap showed the loader making calls to various blockchain APIs to retrieve its second-stage payloads. This tangible evidence validated the novel blockchain-based C2 mechanism and provided concrete proof of the malware's communication strategy.

In essence, the "demo" of this talk was a forensic reconstruction and explanation of the attacker's methods, supported by actual artifacts and code snippets from the discovered campaign, rather than an active exploit demonstration. This approach allowed the speakers to convey the gravity and technical sophistication of the threat without re-enacting a live attack.

Defensive Implications

▶ Watch: Malware analysis: obfuscation and unique campaign tags (6:59)

Lovable's response to this sophisticated campaign provides critical insights for defenders facing similar threats, particularly in platforms that handle user-generated code or rely on external repository access.

Upon discovering the initial infection, Lovable initiated a massive retroactive analysis. They built internal tools to scan the entire Git history of millions of projects. This involved running a large cluster of Google Cloud compute engines, processing approximately 500,000 projects in parallel at any given time, allowing for a full analysis of 7 million projects and 100 billion lines of code within a few days. This proactive threat hunting revealed the true scale of the campaign (400+ affected projects) and its longevity, dating back to March 2025. This highlights the importance of having robust, scalable code scanning capabilities.

For ongoing defense, Lovable significantly enhanced its detection capabilities. This involved:

• Internal Tools: Leveraging their own agent runtime tools to gather additional telemetry and integrate custom detections.
• External Vendors: Partnering with specialized external security vendors to augment their analysis and detection scope.
• IOC Tracking: Actively tracking Indicators of Compromise (IOCs), including domain names (which remained surprisingly consistent despite rotating IPs), and monitoring the adversary's extensive fleet of AWS load balancers and Nginx proxies. This allowed them to track the campaign's evolution and identify other related campaigns.

Key lessons learned for defenders include:

1. CI/CD Hardening: The attack exploited the build process. Organizations must rigorously harden their CI/CD pipelines, focusing on how code is tested, which code is trusted, and the sandbox environments. While difficult to prevent purely social engineering attacks, robust CI/CD security can limit the impact of successful code injections.
2. Proactive Threat Hunting: The ability to perform large-scale, deep code analysis on historical data was crucial for understanding the scope and nature of the attack. Developing internal platforms for vulnerability management, patching, and general code searching is highly recommended for any organization managing a significant codebase.
3. Awareness of Social Engineering: Recognize that sophisticated social engineering remains a primary vector for gaining initial access. Training users and developers to identify and report suspicious interactions is paramount.
4. Monitoring External Access: Platforms that integrate with external services like GitHub must have robust monitoring and auditing for access changes, particularly when dealing with third-party collaborators.
5. Evolving Detection Strategies: Signature-based detections are insufficient against highly obfuscated and polymorphic malware. Defenders need to invest in behavioral analysis, runtime detection, and techniques that can identify dynamic code execution and unusual C2 patterns (like blockchain communication).
6. Incident Response Planning: A well-defined incident response plan, including preparedness for large-scale data analysis and remediation, is essential. Lovable worked with all affected customers to remediate the compromises, demonstrating a commitment to user security.

The Lovable platform itself was not compromised, reiterating that the focus of this attack was on individual user projects via social engineering. This distinction is vital for understanding the attack surface and designing appropriate defenses. The talk serves as a stark reminder that even with advanced platform security, the human element and the supply chain of code remain critical vulnerabilities.

Key Takeaways

• Social Engineering is a Primary Vector: Even with robust platform security, sophisticated social engineering remains a highly effective method for attackers to gain initial access to user projects and repositories.
• Malware Obfuscation is Advanced: Attackers employ multi-stage loaders, seeded deterministic shuffles, and dynamic function construction (without explicit keywords) to create polymorphic malware that evades hash-based and static signature detections.
• Blockchains as C2 are a Novel Threat: Using public, immutable blockchains for command-and-control (C2) makes payloads resilient to takedown and difficult to trace, representing a significant evolution in attacker evasion techniques.
• CI/CD Pipelines are Critical Attack Surfaces: Malicious code injected into configuration files within build processes can escape sandboxes by detaching child processes, gaining full access to the local environment.
• Large-Scale Retroactive Analysis is Essential: The ability to perform rapid, comprehensive historical code scanning across millions of projects is vital for understanding the scope of campaigns and identifying long-running threats.
• Multi-faceted Detection is Required: A combination of internal runtime agents, external vendor tools, and active IOC tracking (including domain analysis and fleet monitoring) is necessary to detect and respond to evolving, sophisticated threats.

About the Speaker(s)

Samuel is a Security Engineer at Lovable. In this role, he played a key part in the investigation and analysis of the malicious code injection campaign, demonstrating a deep technical understanding of malware analysis, obfuscation techniques, and incident response. His presentation focused heavily on the technical intricacies of the loader malware and its execution.

Marcus is also from Lovable, though his specific title was not mentioned in the introduction. He joined Samuel in presenting the talk, focusing on the broader context of the attack, Lovable's platform, the company's response, and the lessons learned. His insights covered the strategic aspects of handling such a large-scale security incident and the defensive implications for the community.