Cyber Kendra

Ubuntu's X Account Appears Hijacked to Push Fake "Numbat" Solana AI Agent Crypto Scam

protalweb@gmail.com (Vivek Gurung) — Thu, 7 May 2026 09:47:00 +0530

Ubuntu users and open-source enthusiasts should be on high alert: a sophisticated impersonation campaign is exploiting Ubuntu's branding — and possibly its official X (formerly Twitter) account — to lure victims into a crypto airdrop scam tied to a fake AI agent called "Numbat."

The fraudulent campaign surfaced today, May 7, through a thread posted from @ubuntu on X, announcing "Numbat" as "Ubuntu's newest AI agent built on Solana" and directing followers to ai-ubuntu.com.

The thread even carries the hallmark self-awareness of a compromised account: the final tweet states comments were disabled "due to suspicious links and impersonation attempts" — while the thread itself is the suspicious impersonation.

The Scam Unpacked

The ai-ubuntu.com website is a carefully assembled forgery. It lifts real Ubuntu AI documentation wholesale — references to Charmed Kubeflow, Canonical's NVIDIA partnership, MLOps workflows, and Canonical's actual open-source AI tools — and wraps them around fake crypto incentives.

Buried in the legitimately sourced content is the scam's actual payload: a "$UM token" airdrop promising "future allocations" to early ecosystem participants, with an ominous "Snapshot approaching" countdown designed to manufacture urgency.

This technique — blending genuine technical content with fraudulent incentive structures — is increasingly common in brand impersonation attacks targeting developer and open-source communities, where technical credibility lowers victims' guard.

Cyber Kendra checked the WHOIS record for the domain and found that it was registered on May 06, 2026 (a day before), with the Registrar: NICENIC INTERNATIONAL GROUP CO., LIMITED.

Whois records

What This Looks Like in Practice

Whether the @ubuntu account was directly compromised or the X profile was spoofed, the attack follows a well-worn playbook: impersonate a trusted tech brand, invoke AI and blockchain buzzwords to signal legitimacy, dangle token rewards for early participants, then harvest wallet connections or personal data through the "eligibility check" flow on the fraudulent site.

The second document — appearing to mirror ai-ubuntu.com's landing page — reinforces the con by using real Ubuntu workstation imagery, authentic tool logos (TensorFlow, PyTorch, Jupyter, Kafka), and real Canonical partner branding to pass visual inspection.

Scammers simply copied the official Ubuntu AI page and added altered text. [Check Image for difference]

Fake Ubuntu AI webpage

Official Ubuntu AI webpage

What You Should Do

Do not visit ai-ubuntu.com or connect any wallet to the site. Do not click links from the @ubuntu X thread. Verify any Ubuntu AI announcements exclusively through ubuntu.com and canonical.com. If you've already interacted with the site, revoke any wallet permissions immediately and monitor connected accounts for unauthorised activity.

Canonical has not issued a public statement at the time of writing. Cyber Kendra has reached out for comment.

The incident is a sharp reminder that even trusted open-source brand accounts are prime targets — and that crypto airdrop language should always trigger immediate scepticism, regardless of how official the surrounding content looks.

Why Ignoring IT Support Can Cost Your Business More

protalweb@gmail.com (Vivek Gurung) — Thu, 7 May 2026 07:41:00 +0530

At first glance, skipping proper IT support is a way to save money. After all, if everything appears to be working, why invest in something that feels unnecessary? Well… that is where many businesses get caught off guard.

Technology rarely fails all at once. Instead, problems build quietly in the background – slower systems, missed updates, small glitches. Over time, these issues turn into costly disruptions. Businesses that delay proper IT support often end up paying far more than they expected.

That is why experienced providers such as Sereno IT Support emphasize proactive care rather than reactive fixes. In this article, we will explore the hidden costs of neglecting IT support and why investing in it is essential for long-term success.

What Does “Neglecting IT Support” Really Mean?

Neglecting IT support does not always mean ignoring technology completely. More often, it involves:

Delaying system updates
Ignoring minor technical issues
Using outdated software or hardware
Lacking proper security measures
Having no dedicated IT support strategy

These decisions may seem harmless at first, but they can lead to serious consequences over time.

Increased Downtime and Business Interruptions

One of the most immediate costs of poor IT support is downtime.

When systems fail, employees cannot access files, send emails, or complete tasks. Even a short interruption can disrupt operations.

The real impact

Lost working hours
Missed deadlines
Delayed customer responses

Over time, these interruptions add up and affect overall business performance.

Reduced Employee Productivity

Slow systems and frequent technical issues can frustrate employees.

Instead of focusing on their tasks, they may spend time:

Restarting systems
Troubleshooting problems
Waiting for the software to respond

Productivity loss example

Even losing 15–20 minutes per day per employee can result in significant losses over the course of a year.

Higher Long-Term Repair Costs

Ignoring small issues often leads to bigger problems.

What starts small can grow

A minor software glitch becomes a system failure
Outdated hardware breaks down completely
Unpatched systems become vulnerable

Fixing major issues is usually far more expensive than regularly maintaining systems.

Cybersecurity Risks and Data Breaches

One of the most serious hidden costs is poor cybersecurity.

Without proper IT support, businesses may:

Miss important security updates
Use weak passwords
Lack of monitoring systems

Consequences

Data breaches
Financial losses
Damage to reputation

Cyber incidents can take months – or even years – to recover from.

Loss of Valuable Data

Data is one of the most important assets a business has.

Without proper backup systems, data can be lost due to:

Hardware failure
Human error
Cyber attacks

Recovering lost data is often difficult, expensive, or even impossible.

Damage to Business Reputation

Customers expect reliable service. When systems fail or data is compromised, trust can be affected.

Examples

Delayed responses to clients
Lost customer information
Service interruptions

Rebuilding trust takes time and effort.

Inefficient Business Processes

Outdated or poorly maintained systems can slow down workflows.

Common issues

Manual processes instead of automation
Poor integration between systems
Difficulty accessing information

These inefficiencies reduce overall productivity and increase operational costs.

Lack of Scalability

Businesses grow – and their technology needs grow too.

Without proper IT support, systems may struggle to handle increased demand.

Result

Slow performance
System crashes
Limited ability to expand

Neglecting IT support can limit business growth.

Compliance and Legal Risks

Many industries have strict regulations regarding data protection and security.

Without proper IT management, businesses may fail to meet these requirements.

Possible consequences

Legal penalties
Fines
Loss of certifications

Compliance is not optional – it is essential.

Summary of Hidden Costs

Issue	Business Impact
Downtime	Lost productivity and revenue
Security risks	Data breaches and financial loss
Outdated systems	Reduced efficiency
Data loss	Disrupted operations
Poor scalability	Limited growth

Why Proactive IT Support Is the Better Approach

Instead of waiting for problems to occur, proactive IT support focuses on prevention.

Key benefits

Regular system monitoring
Early detection of issues
Improved system performance
Stronger security

This approach reduces risks and keeps systems running smoothly.

Small Issues vs Big Consequences

It is easy to ignore minor IT problems. However, these small issues often lead to larger challenges.

Example

A simple missed update may:

Create security vulnerabilities
Slow down systems
Cause compatibility issues

Addressing small problems early can prevent major disruptions later.

How Businesses Can Avoid These Costs

Preventing IT-related problems does not have to be complicated.

Practical steps

Invest in professional IT support
Keep systems updated
Use secure passwords and networks
Implement regular data backups
Monitor systems continuously

These actions help maintain a stable and secure IT environment.

Frequently Asked Questions

Q. Why do businesses neglect IT support?

A. Often to reduce costs or because they underestimate the risks.

Q. Can small businesses afford IT support?

A. Yes. Many providers offer flexible solutions tailored to different budgets.

Q. Is reactive IT support enough?

A. Reactive support helps fix problems, but proactive support prevents them.

Q. What is the biggest risk of neglecting IT?

A. Cybersecurity threats and data loss are among the most serious risks.

Conclusion

Neglecting IT support may seem like a way to save money in the short term, but the hidden costs can be significant. From downtime and lost productivity to cybersecurity risks and damaged reputation, the impact can affect every part of a business.

Investing in reliable IT support helps prevent these problems, ensuring systems run smoothly and securely. With the right approach, businesses can reduce risks, improve efficiency, and focus on growth.

In today’s digital world, IT support is not just an option – it is a necessity for long-term success.

Palo Alto PAN-OS Zero-Day Under Active Attack — No Patch Available Yet

protalweb@gmail.com (Vivek Gurung) — Wed, 6 May 2026 19:34:00 +0530

Attackers are already exploiting a critical zero-day vulnerability in Palo Alto Networks' PAN-OS, the operating system powering the company's widely deployed enterprise firewalls — and patches won't arrive until May 13 at the earliest.

The flaw, tracked as CVE-2026-0300, is a buffer overflow in the User-ID Authentication Portal — also known as the Captive Portal — a PAN-OS feature that authenticates users when the firewall cannot automatically map an IP address to a known identity. The vulnerability carries a CVSS 4.0 score of 9.3, placing it firmly in the Critical tier.

The zero-day allows unauthenticated attackers to execute arbitrary code with root privileges on internet-exposed PA-Series and VM-Series firewalls by sending specially crafted network packets. In plain terms: no login, no credentials, full ownership of the firewall.

In-Wild Exploitation

Palo Alto Networks confirmed in its advisory that "limited exploitation has been observed targeting Palo Alto Networks User-ID Authentication Portals that are exposed to untrusted IP addresses and/or the public internet." In the threat intelligence community, "limited exploitation" is typically code for highly targeted attacks — often the calling card of nation-state actors probing high-value networks.

Internet threat watchdog Shadowserver is currently tracking over 5,800 PAN-OS VM-Series firewalls exposed online, with the largest concentrations in Asia (2,466 devices) and North America (1,998). Every one of those devices is a potential target if the Captive Portal is enabled and reachable from the internet.

The vulnerability has already reached the "ATTACKED" stage in exploit maturity, and Palo Alto has confirmed that exploitation of CVE-2026-0300 is automatable — meaning threat actors can script and scale attacks without manual intervention.

What Makes This Particularly Dangerous

The flaw is rooted in CWE-787 (Out-of-bounds Write), a class of memory corruption bugs that allow attackers to overwrite adjacent memory and redirect program execution. Because the Authentication Portal is a network-facing service, no user interaction is required — an attacker anywhere on the internet can trigger the exploit if the portal is left exposed.

Prisma Access, Cloud NGFW, and Panorama appliances are not impacted by this vulnerability. The risk is confined strictly to PA-Series and VM-Series hardware and virtual firewalls with the User-ID Authentication Portal switched on.

Patches Coming in Waves

Patches are rolling out in a staggered schedule between May 13 and May 28, 2026, depending on the PAN-OS branch. Additionally, Palo Alto released a Threat Prevention Signature for PAN-OS 11.1 and above starting May 5, 2026, which can detect and block exploitation attempts.

CISA's Known Exploited Vulnerabilities catalog currently includes 13 Palo Alto product vulnerabilities, but CVE-2026-0300 has not yet been added — an addition that may well come soon, given confirmed in-the-wild exploitation. Given that Palo Alto Networks' products are used by over 70,000 customers worldwide, including 90% of Fortune 10 companies, the blast radius of widespread exploitation would be enormous.

What Administrators Should Do Right Now

Patches aren't here yet, but mitigation options exist. Palo Alto recommends one of two immediate actions:

Restrict access to the User-ID Authentication Portal to trusted internal IP addresses only — eliminating internet exposure entirely.
Disable the Authentication Portal outright if your organization doesn't actively use it.

Administrators should verify their exposure status by navigating to Device → User Identification → Authentication Portal Settings → Enable Authentication Portal in the PAN-OS management interface. If that setting is enabled and the portal is reachable from an untrusted network, treat it as a live incident-in-waiting.

Apply the Threat Prevention Signature update immediately (via Device → Dynamic Updates) and schedule patching to the fixed PAN-OS versions the moment they become available on May 13.

Apache HTTP Server's HTTP/2 Module Has a Memory Bug That Can Crash or Compromise Your Server

protalweb@gmail.com (Vivek Gurung) — Wed, 6 May 2026 09:04:00 +0530

A memory management flaw buried inside Apache HTTP Server's HTTP/2 module is giving attackers two options: crash your web server with a two-frame network packet, or — under the right conditions — run arbitrary code on it.

The Apache Software Foundation shipped a fix on May 4 as part of the 2.4.67 release, but every installation still running 2.4.66 with HTTP/2 enabled is exposed right now.

The vulnerability, CVE-2026-23918 (CVSS 8.8), was discovered by Bartlomiej Dmitruk, co-founder of Striga.ai, and Stanislaw Strzalkowski of ISEC.pl. It is a double-free — a class of memory corruption bug where the same chunk of memory gets released twice — inside h2_mplx.c, the stream cleanup path of mod_http2.

What triggers it?

The bug fires when a client sends an HTTP/2 HEADERS frame immediately followed by an RST_STREAM frame on the same stream before the server's multiplexer has had a chance to register the stream. Two internal callbacks — on_frame_recv_cb and on_stream_close_cb — both fire in rapid succession and independently walk the same cleanup path, pushing the same stream pointer into the purge queue twice.

When Apache later iterates that queue and calls apr_pool_destroy on each entry, the second call hits memory that is already gone.

Two outcomes, very different threat levels

The DoS is the easy one. Dmitruk described it bluntly: one TCP connection, two frames, no authentication, no special headers, no specific URL. The worker process crashes. Apache respawns it automatically, but every request it was handling is dropped — and an attacker can keep cycling this indefinitely.

The remote code execution scenario is more demanding but not theoretical. The research team built a working proof-of-concept on x86-64. It exploits the freed memory via mmap reuse to plant a fake stream structure pointing Apache's own pool cleanup function at system().

The key enabler is Apache's scoreboard memory, which sits at a fixed address for the entire lifetime of the server process — even with ASLR (address space layout randomization) active — giving attackers a stable target. The RCE path specifically requires Apache Portable Runtime (APR) compiled with the mmap allocator, which happens to be the default on Debian-based Linux systems and the official Apache httpd Docker image.

One important carve-out: the MPM prefork mode is not affected. But because mod_http2 ships enabled in default Apache builds and HTTP/2 is standard in most production environments today, the exposed attack surface is significant.

The bigger patch batch

The 2.4.67 update patches nine additional vulnerabilities alongside CVE-2026-23918, including a moderate privilege escalation in mod_rewrite (CVE-2026-24072), a timing attack against digest authentication (CVE-2026-33006), and a cluster of AJP proxy memory-handling issues.

Upgrade to Apache HTTP Server 2.4.67 immediately. If an immediate upgrade is not feasible, disabling mod_http2 removes the primary attack surface for CVE-2026-23918. Operators running Debian-derived systems or the official Docker image should treat the RCE risk as real and urgent, not theoretical.

Google Chrome Is Silently Pushing a 4 GB AI Model to Your Device — And Reinstalls It If You Delete It

protalweb@gmail.com (Vivek Gurung) — Wed, 6 May 2026 08:14:00 +0530

Hundreds of millions of Chrome users have a 4 GB AI model sitting on their hard drives right now — and most of them never agreed to it.

Security and privacy researcher Alexander Hanff, writing under the alias "That Privacy Guy," published a detailed investigation last week revealing that Google Chrome silently downloads the Gemini Nano weight file — Google's on-device large language model — to user devices without any consent prompt.

The file, named weights.bin, is located in a directory called OptGuideOnDeviceModel, buried deep within the Chrome user profile. Delete it, and Chrome will download it again in the next eligible window.

Hanff created a fresh Chrome profile on Apple Silicon specifically for an automated privacy audit. The profile received zero keyboard or mouse input from a human at any point. Using macOS's low-level filesystem event log (.fseventsd) — which Chrome cannot modify — he traced the exact moment the model landed.

The next day of creating a fresh profile, Chrome created the OptGuideOnDeviceModel directory, spawned three background unpacker subprocesses, and completed the full 4 GB install in just 14 minutes and 28 seconds, while a tab sat idle waiting for a timer to expire.

Chrome's internal feature flags confirm that the download begins before the Settings UI that would let a user refuse is even visible — meaning the architecture ensures installation precedes any opportunity to opt out.

Chrome 147 displays a prominent "AI Mode" pill in the address bar — the most visible AI touchpoint in the entire browser. A reasonable user would assume that the pill is powered by the local Gemini Nano model sitting on their disk. It is not.

The AI Mode feature routes every query to Google's cloud servers. The on-device model powers buried features like "Help me write" in text boxes and tab-group suggestions — things most users will never discover. Users pay for storage and bandwidth; the headline feature phones home anyway.

How to Block It

Stopping the download is not straightforward for ordinary users:

Chrome flags (Chrome 137+): Open chrome://flags, search "optimisation guide on device", and set it to Disabled. Note that flags can reset after major browser updates.
Windows Registry: Set OptimizationGuideModelDownloading to 0 under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. Requires admin rights.
Enterprise environments can enforce the block via Group Policy.

There is no single-click opt-out in Chrome's standard Settings for home users.

Google has not publicly responded to the investigation or addressed the absence of a consent prompt. Hanff argues that the behaviour directly violates the EU's ePrivacy Directive (Article 5(3)) and the GDPR's data minimisation principles — the same legal framework he previously applied to Anthropic's Claude Desktop, which silently registered automation hooks across seven Chromium-based browsers.

WhatsApp Quietly Fixed Two Flaws That Could Make Malware Look Like a PDF

protalweb@gmail.com (Vivek Gurung) — Wed, 6 May 2026 07:54:00 +0530

If you use WhatsApp on Windows, here is something worth knowing: until recently, an attacker could send you what looked like a harmless document — a PDF, an invoice, a document, or anything — and the moment you opened it, your machine would execute it as a program. Meta has now patched that flaw, along with a second vulnerability tied to WhatsApp's AI integration with Instagram Reels.

Meta disclosed both issues through its official security advisories this week. Neither has been observed in the wild to be exploited, and fixes are already live — but the mechanics of both bugs are worth understanding.

The Windows Attachment Trick

CVE-2026-23863 is a file spoofing vulnerability affecting WhatsApp for Windows versions prior to v2.3000.1032164386.258709. The attacker embeds NUL bytes (null characters invisible to the user interface) inside a file's name.

WhatsApp's Windows client would render the file as a benign document type — say, a .pdf — while the operating system would read past the NUL byte and execute it as something else entirely, such as an .exe. It is a deceptive technique that has existed in some form for decades and remains effective when applications fail to properly sanitise filenames.

The Instagram Reels AI Angle

The second flaw, CVE-2026-23866, sits on a less obvious attack surface: WhatsApp's handling of AI-generated rich response messages for Instagram Reels. Due to incomplete validation, a malicious actor could cause a target device to load media from an arbitrary URL—and, more critically, invoke OS-level custom URL scheme handlers.

On iOS and Android, custom URL schemes (facetime:, tel:, itms-apps:, or third-party app deep links) can be weaponized to redirect users to phishing pages, silently open apps, or probe installed software. The flaw affected WhatsApp for iOS v2.25.8.0 through v2.26.15.72 and Android v2.25.8.0 through v2.26.7.10.

Both vulnerabilities were responsibly disclosed by anonymous external researchers through Meta's bug bounty programme.

Update WhatsApp immediately, on every platform you use it. On Windows, confirm you are running v2.3000.1032164386.258709 or later. On mobile, any version above v2.26.15.72 (iOS) or v2.26.7.10 (Android) is patched.

The broader takeaway: as messaging apps deepen integration with AI features and cross-platform content — like Reels previews inside WhatsApp — the attack surface expands in ways that are not always obvious. Meta caught these before threat actors could, but the window between discovery and disclosure is rarely zero.

Top 11 AI-Powered GRC Platforms to Watch Out For in 2026

protalweb@gmail.com (Vivek Gurung) — Sun, 3 May 2026 21:39:00 +0530

Organizations face mounting pressure to demonstrate compliance across multiple frameworks while quantifying cyber risk in terms that boards understand. Manual spreadsheets and siloed tools no longer scale when audit teams juggle simultaneous certifications for SOC 2, ISO 27001, HIPAA, and emerging regulations like DORA.

Risk managers need platforms that translate technical vulnerabilities into business impact and automate repetitive control testing without adding headcount.

AI-powered GRC platforms now deliver automated risk assessments, cross-framework control mapping, and real-time monitoring, reducing audit preparation time from months to weeks. Machine learning algorithms match controls across dozens of standards, populate risk registers from live data sources, and generate board-ready reports that connect security posture to enterprise risk appetite.

These systems handle vendor risk workflows, gap analysis, and remediation tracking in unified interfaces that replace fragmented toolchains.

This analysis examines platforms built for multi-framework compliance, quantified risk management, and continuous control monitoring. Selection criteria include automation depth, framework coverage, vendor risk capabilities, and deployment speed for mid-market and enterprise buyers.

Best AI-Powered GRC Platforms to watch out for 2026

1. Centraleyes - The Best AI Risk Governance Built for the Threat Landscape Ahead

Centraleyes takes a different architectural approach to GRC: instead of asking teams to define risk scenarios manually, the platform's AI engine generates and updates them continuously - pulling from live threat intelligence feeds, asset inventories, and control gap data to surface what's relevant right now, not what was relevant at last year's audit. Security and compliance teams moving away from yesterday's GRC tools are finding this shift from static to dynamic risk management is exactly what modern threat environments demand.

Centraleyes is selected as the best AI-powered GRC platform for 2026, and is definitely one of the top companies to watch. The company built a proprietary AI governance module that treats AI systems as a manageable risk domain - mapping AI-specific controls into the same workflows used for cyber and regulatory risk.

As organizations face growing pressure to demonstrate responsible AI use to boards and regulators, this positions Centraleyes ahead of platforms still retrofitting AI features onto legacy GRC architecture.

The no-code deployment model means compliance teams can activate new framework modules - including DORA, CMMC 2.0, and emerging regional AI regulations - without IT involvement or implementation projects. Organizations entering a new regulatory environment for the first time can be operationally compliant within 30 days.

Key capabilities

Continuously updated AI risk register driven by live threat intelligence
Proprietary AI governance framework for managing AI as an enterprise risk domain
No-code framework activation for emerging regulations without IT dependency
Cross-framework control mapping, eliminating redundant evidence collection
Board-ready risk reporting in business language, not security jargon

2. OneTrust – Privacy-First GRC for Global Operations

OneTrust extends privacy and data governance capabilities into broader GRC workflows, serving multinational organizations managing GDPR, CCPA, and sector-specific mandates. The platform integrates consent management, data mapping, and incident response with compliance tracking across regional regulations.

Large enterprises with complex data residency requirements use OneTrust to coordinate privacy impact assessments alongside traditional risk management. The system handles vendor assessments through privacy-specific questionnaires that evaluate data processing agreements and cross-border data flows.

Key capabilities

Privacy and data governance with consent tracking
Automated data subject access request workflows
Cookie compliance and website scanning tools
Third-party risk assessment with privacy questionnaires
Regional regulation tracking for GDPR and CCPA

3. LogicGate – Configurable Workflows for Risk Teams

LogicGate provides low-code workflow builders that let risk teams design custom GRC processes without developer support. Organizations with unique operational risk frameworks use LogicGate to model industry-specific scenarios not covered by standard compliance templates.

Mid-market companies and business units within larger enterprises adopt LogicGate when off-the-shelf workflows do not align with their existing governance structures. The platform supports enterprise risk management programs that extend beyond IT security into operational and strategic risk domains.

Key capabilities

Low-code workflow engine for custom process design
Risk register with configurable scoring methodologies
Operational risk tracking beyond security compliance
Integration with existing business intelligence tools
Visual process mapping for governance documentation

4. SAI360 – Enterprise Risk Across Business Functions

SAI360 addresses enterprise risk management across compliance, ethics, learning, and environmental health and safety programs. The platform serves industries with operational risk exposures spanning workplace safety, regulatory compliance, and corporate governance.

Manufacturing firms and multinational corporations use SAI360 to centralize risk data from geographically distributed operations. The system connects incident reporting from factory floors with executive risk committees through configurable escalation rules and dashboards.

Key capabilities

Enterprise risk management across multiple business functions
Ethics and compliance hotline with case management
Environmental health and safety incident tracking
Policy management with attestation workflows
Audit planning and execution with finding tracking

5. Fusion Risk Management – Business Continuity Planning

Fusion Risk Management focuses on business continuity, disaster recovery, and operational resilience alongside traditional GRC functions. Organizations in critical infrastructure sectors use Fusion to model recovery time objectives and coordinate crisis response across distributed teams.

Financial institutions and healthcare systems rely on Fusion to meet regulatory requirements for operational resilience and business continuity testing. The platform maps critical business processes to supporting technology and third-party dependencies for impact analysis during disruption scenarios.

Key capabilities

Business continuity planning with recovery time tracking
Crisis management and incident command coordination
Business impact analysis for critical processes
Third-party dependency mapping for resilience
Tabletop exercise management and documentation

6. Prevalent – Third-Party Risk Intelligence

Prevalent specializes in vendor risk management with automated security assessments and continuous monitoring of supplier ecosystems. The platform aggregates threat intelligence, financial health data, and security ratings to score third-party risk without manual questionnaires.

Procurement teams managing hundreds of vendor relationships use Prevalent to automate initial assessments and trigger reviews when supplier risk profiles change. Financial services and healthcare organizations rely on continuous monitoring to detect vendor security incidents between annual audits.

Key capabilities

Automated vendor security assessments with intelligence feeds
Continuous monitoring of third-party security posture
Financial health and cyber risk scoring
Questionnaire automation with pre-filled responses
Vendor portfolio risk aggregation and reporting

7. Vanta – Automated Compliance for Cloud-Native Teams

Vanta automates evidence collection for SOC 2, ISO 27001, and HIPAA certifications by integrating directly with cloud infrastructure and SaaS tools. The platform monitors security controls continuously and alerts teams when configurations drift from compliance requirements.

Technology startups and SaaS companies use Vanta to achieve first-time certifications quickly and maintain compliance as they scale. The system reduces audit preparation time by automatically gathering screenshots, configuration exports, and access logs that auditors require.

Key capabilities

Automated evidence collection from cloud infrastructure
Continuous control monitoring with drift detection
SOC 2 and ISO 27001 certification preparation
Integration with AWS, Azure, GCP, and SaaS tools
Audit coordination with document sharing portals

8. Drata – Continuous Compliance Monitoring

Drata provides continuous monitoring and automated testing for compliance frameworks such as SOC 2, ISO 27001, and GDPR. The platform connects to endpoint management, HR systems, and cloud providers to verify control effectiveness in real time.

Fast-growing technology companies use Drata to maintain compliance during rapid hiring and infrastructure changes. The system documents personnel onboarding, device management, and access review processes automatically, reducing manual evidence preparation during audits.

Key capabilities

Continuous compliance monitoring across multiple frameworks
Automated employee onboarding and offboarding checks
Background check and training completion tracking
Integration with identity providers and endpoint tools
Policy management with employee acknowledgment workflows

9. Secureframe – Compliance for Growing Technology Firms

Secureframe simplifies compliance for technology companies pursuing SOC 2, ISO 27001, and PCI DSS certifications. The platform automates responses to security questionnaires and maintains vendor risk assessments to meet supply chain compliance requirements.

Series A and Series B-stage companies use Secureframe to demonstrate their security posture to enterprise customers and investors. The system generates trust reports that summarize compliance status and security controls for sales teams responding to security reviews.

Key capabilities

Automated compliance workflows for SOC 2 and ISO
Security questionnaire automation with AI responses
Vendor risk assessment and documentation
Trust center for customer security communications
Integration with development and infrastructure tools

10. Tugboat Logic – Risk-Based Compliance Management

Tugboat Logic connects risk management methodologies with compliance automation for organizations pursuing multiple security certifications. The platform provides pre-built control libraries and policy templates that adapt to industry-specific requirements.

Companies in regulated industries use Tugboat Logic to document control environments and prepare for external audits. The system maps internal controls to framework requirements and tracks remediation activities through integrated workflow tools.

Key capabilities

Risk-based approach to compliance management
Pre-built policy and procedure templates
Control mapping across security frameworks
Vendor risk management with assessment workflows
Audit preparation and evidence collection

11. Sprinto – Compliance Automation for Global Standards

Sprinto automates compliance for international standards, including SOC 2, ISO 27001, GDPR, and HIPAA, through integrations with cloud infrastructure and business systems. The platform monitors security controls and generates compliance reports for audit teams.

International technology companies use Sprinto to manage compliance across regional requirements as they expand into new markets. The system tracks control changes over time and maintains historical evidence for multi-year audit cycles.

Key capabilities

Automated compliance for global security standards
Real-time control monitoring with alerting
Integration with cloud providers and SaaS platforms
Compliance dashboard with framework progress tracking
Evidence vault for historical audit documentation

How AI Transforms GRC Operations

Organizations evaluating GRC platforms should understand where artificial intelligence delivers measurable value versus marketing claims:

Automated Control Mapping

Natural language processing matches controls across frameworks
Identifies overlapping requirements between standards automatically
Suggests control implementations based on infrastructure configuration
Reduces manual mapping time from weeks to hours

Risk Quantification and Scoring

Machine learning calculates the financial impact from vulnerability data
Prioritizes remediation based on threat intelligence feeds
Updates risk scores continuously as environments change
Translates technical findings into business risk language

Evidence Collection and Monitoring

Automated screenshot capture and log extraction
Continuous validation of control effectiveness through API integrations
Anomaly detection for configuration drift from baselines
Smart questionnaire routing based on response patterns

Key Criteria for Evaluating GRC Platforms

Procurement teams should assess these dimensions when comparing platforms:

Framework Coverage and Mapping

Number of pre-built framework libraries included
Quality of control mapping between overlapping standards
Frequency of framework updates for regulatory changes
Support for industry-specific and regional requirements

Integration Architecture

Native connectors to cloud infrastructure providers
API availability for custom data sources
Ticketing system integration for remediation workflows
Identity provider support for user provisioning

Deployment and Time to Value

Implementation timeline without professional services
Configuration requirements for basic functionality
Training needs for compliance and security teams
Time required to complete the first risk assessment

Who Should Use AI-Powered GRC Platforms

Different organizational profiles benefit from GRC automation in distinct ways:

Enterprises with Multi-Framework Requirements

Organizations pursuing SOC 2, ISO, and NIST simultaneously
Companies managing regional compliance across multiple jurisdictions
Firms with subsidiary-specific certification needs
Businesses are facing continuous audit cycles year-round

Fast-Growth Technology Companies

Startups securing enterprise customers requiring security attestations
SaaS providers maintaining compliance during rapid scaling
Companies with small security teams managing complex toolchains
Organizations entering regulated markets for the first time

Regulated Industry Operators

Healthcare organizations managing HIPAA and state privacy laws
Financial services firms coordinating PCI and SOC requirements
Critical infrastructure providers meeting CMMC standards
Public companies addressing SOX controls and audit readiness

Integration and Compatibility Considerations

Technical compatibility determines whether GRC platforms fit existing infrastructure:

Cloud Infrastructure and Security Tools

AWS, Azure, and GCP configuration monitoring
SIEM and log aggregation platform integration
Vulnerability scanner data import and correlation
Cloud security posture management tool connectivity

Identity and Access Management

Single sign-on with Okta, Azure AD, and Google
User provisioning and deprovisioning automation
Role-based access control with custom permission models
Access review workflows with manager approval chains

Business Systems and Workflow Tools

Jira ServiceNow and Asana for remediation tracking
Slack and Teams for alert notifications
Email systems for automated evidence requests
Document repositories for policy management

FAQs

Q. What is the typical implementation timeline for a GRC platform?

A. Most modern GRC platforms deploy in 30 to 90 days, depending on organizational complexity and integration requirements. No-code platforms with pre-built framework templates enable faster onboarding, while custom implementations requiring extensive configuration can take more than 6 months.
Organizations should evaluate whether vendors offer guided setup assistance and the level of internal IT involvement required for deployment. Platforms with automated discovery and integration wizards typically achieve faster time-to-value than those that require manual data entry.

Q. How do GRC platforms handle multiple business units with different compliance needs?

A. Enterprise-grade platforms provide multi-tenancy architectures that isolate compliance programs by subsidiary, region, or business unit while enabling consolidated reporting for corporate risk committees. Each tenant maintains separate control libraries, risk registers, and audit workflows with inheritance models that apply parent policies to child entities.
Organizations should verify whether platforms support cross-tenant control mapping and whether users can switch between tenant views without separate login credentials.

Q. Can GRC platforms replace manual auditor interactions during certification processes?

A. GRC platforms automate evidence collection and documentation preparation, but do not eliminate auditor engagement during formal certification processes. Platforms reduce audit preparation time by enabling continuous compliance monitoring and generating organized evidence packages for auditors to review.
Organizations still participate in opening meetings, walkthroughs, and testing validation with external auditors. The value lies in reducing weeks of manual preparation work to days and maintaining year-round audit readiness.

Q. What differentiates vendor risk management features across GRC platforms?

A. Advanced platforms integrate vendor risk workflows directly into procurement processes and continuously monitor supplier security posture using external ratings and threat intelligence. Basic implementations treat vendor risk as separate questionnaire modules without integration into supply chain systems.
Organizations managing large vendor portfolios should evaluate automated assessment distribution, response tracking, risk scoring methodologies, and renewal workflows. Continuous monitoring capabilities that detect vendor security incidents between assessment cycles provide significant advantages over annual review approaches.

Q. How do organizations measure ROI from GRC platform investments?

A. Quantifiable benefits include reduced audit preparation time, faster certification cycles, and decreased reliance on external consultants for compliance management. Organizations typically track hours saved on evidence collection, the number of frameworks managed per FTE, and time to complete risk assessments.
Risk quantification features enable comparison of security investments against potential loss exposure, helping justify control implementations. Multi-framework deployments deliver ROI by reusing control across overlapping requirements, eliminating redundant assessments.

A 21-Year-Old PHP Vulnerability That Opens the Door to Remote Code Execution

protalweb@gmail.com (Vivek Gurung) — Sat, 2 May 2026 07:52:00 +0530

A security vulnerability that has been hiding inside PHP since 2005 — quietly surviving two decades of audits, engine rewrites, and dozens of related CVEs — has finally been found, and it took an AI to catch it. Yeah, another flaw discovered by AI after the critical Linux Copy Fail flaw, which leads to root access on almost every major Linux distro.

Researchers at Calif published a detailed write-up today revealing a use-after-free (UAF) bug in PHP's unserialize() function, a code path that has been exploitable since PHP 5.1 shipped the Serializable interface twenty-one years ago.

The flaw allows an attacker to achieve remote code execution (RCE) against the latest PHP release, 8.5.5, in roughly 2,000 HTTP requests — with no hardcoded memory offsets and no access to /proc.

The root cause is a two-line omission. PHP uses an internal lock, BG(serialize_lock), to keep each unserialize() call's reference table private. Every user-code dispatch point inside the deserializer — __wakeup, __unserialize, __destruct — increments that lock before running PHP code. One dispatch site, zend_user_unserialize(), the handler for the Serializable interface, never did. The missing increment means a nested unserialize() call inside a class's own unserialize() method silently shares the outer call's memory table.

An attacker who can trigger a property-table resize during that window gets a dangling pointer, which leads to memory corruption and, ultimately, arbitrary code execution.

The bug survived the PHP 7 engine rewrite in 2016 untouched. It also outlived a 2017 decision by the PHP project to stop treating unserialize() memory bugs as security vulnerabilities — a policy that has aged poorly.

How AI Found What Humans Missed

Calif built an audit tool, /php-unserialize-audit, by feeding roughly twenty historical unserialize advisories into Claude and distilling them into a structured bug taxonomy. That tool rediscovered all twelve known phpcodz advisories when run against PHP 5.6.40, then flagged the Serializable reentrancy issue as novel when pointed at 8.5.5.

The pattern echoes what we reported earlier this year when AI-assisted analysis exposed CopyFail, the critical Linux kernel memory corruption vulnerability. In both cases, AI didn't replace researchers — it handled the exhausting pattern-matching work that lets experts focus on what the findings actually mean.

The remote exploit carries a significant precondition: the target application must load a class implementing Serializable that calls unserialize() recursively on user-supplied data and then mutates the resulting object's properties. That combination is uncommon in production code. The local exploit, however, carries no such restriction — any PHP process that passes attacker-controlled input to unserialize() is vulnerable, and the researchers confirmed it bypasses disable_functions entirely.

The researchers have open-sourced both the exploit and the audit skill.

What to Do

Audit any code that passes user input to unserialize() — PHP's own documentation has warned against this for years.
Replace unserialize() with json_decode() wherever possible for untrusted data.
Monitor for PHP patches addressing this Serializable dispatch path.
Treat disable_functions as a speed bump, not a security boundary.

PHP's unserialize() has been a vulnerability factory since 2007. This bug suggests it still has more to give — and that AI-assisted auditing is quickly becoming the tool that will drain it.

Anthropic's Claude Security Is Now Open to All Enterprise Users — AI Catches Bugs

protalweb@gmail.com (Vivek Gurung) — Thu, 30 Apr 2026 23:41:00 +0530

Anthropic has opened Claude Security to all Claude Enterprise customers in public beta, marking a significant shift in how organisations can defend their software.

The tool uses Claude Opus 4.7 — currently one of the strongest generally available models for security analysis — to scan entire codebases, trace how data moves through code, and generate targeted patches for developer review. No custom API integration or agent-building is required; if your organisation already runs Claude, you can point it at a GitHub repository and start scanning today.

The stakes behind this launch are not subtle. Anthropic says that hundreds of organizations tested the tool in a closed research preview since February, uncovering exploits in production code — including vulnerabilities that existing tools had missed for years.

The predecessor model, Claude Opus 4.6, found over 500 vulnerabilities in production open-source codebases — bugs that had gone undetected for decades despite years of expert review. Patches and coordinated disclosures for those findings are ongoing.

How it actually works

Unlike traditional static analysis tools (rule-based scanners that match code against known vulnerability patterns), Claude reads and reasons about code the way a human security researcher would: understanding how components interact, tracing how data moves through an application, and catching complex vulnerabilities that rule-based tools miss.

Every finding then passes through a multi-stage verification pipeline where the model challenges its own conclusions before surfacing results to an analyst, reducing false positives and attaching a confidence rating to each issue.

Findings are organised by severity — High, Medium, or Low — based on exploitability in the specific codebase, not just vulnerability category.

A High-severity finding means an unauthenticated remote attacker could exploit it against a default deployment with no meaningful preconditions. Each finding also includes the affected file and line number, reproduction steps, and a suggested patch users can open directly in Claude Code on the Web to review and apply.

What's new in the public beta

Feedback from the preview shaped several additions in today's release. Teams can now schedule recurring scans — a weekly cadence ties well to sprint boundaries or pre-release checkpoints. Scans can be scoped to a specific directory within a repository, which meaningfully improves success rates on large monorepos.

Dismissed findings can carry documented reasons, building an audit trail for future reviewers. Results export as CSV or Markdown, and per-project webhooks push scan events into Slack, Jira, or other existing tracking systems in real time.

Claude Security sits alongside Anthropic's more restricted Project Glasswing initiative, where the far more capable — and more dangerous — Claude Mythos Preview model is being used with a vetted set of partners. Mythos-class capabilities are expected to become more broadly available within the next year or two, and the volume of downstream vulnerability findings will increase substantially.

Claude Security is Anthropic's answer for the wider enterprise market right now: less powerful, but accessible, with safeguards built in.

On the partner front, CrowdStrike, Palo Alto Networks, SentinelOne, TrendAI, and Wiz are embedding Opus 4.7 into their security platforms, while Accenture, BCG, Deloitte, Infosys, and PwC are helping enterprises deploy Claude-integrated security solutions for vulnerability management, secure code review, and incident response.

Currently, only GitHub-hosted repositories are supported. Access for the Claude Team and Max plan customers is expected soon. Organisations whose legitimate security work triggers Opus 4.7's built-in cyber safeguards can apply for Anthropic's Cyber Verification Program to continue operating without interruption.

Lightning PyPI Package Compromised in Supply Chain Attack

protalweb@gmail.com (Vivek Gurung) — Thu, 30 Apr 2026 20:15:00 +0530

If you're building, training, or shipping AI models with PyTorch Lightning, check your installed version immediately — two freshly published releases of the lightning package on PyPI have been weaponised to silently steal credentials the moment you import the library.

Socket's research team today confirmed that versions 2.6.2 and 2.6.3 of the popular deep learning framework are malicious. Version 2.6.1, published January 30, 2026, is clean. Version 2.6.2, published today (April 30, 2026), is where the malicious code was introduced — and Socket's AI scanner flagged both versions as potentially malicious just eighteen minutes after publication.

The timing is critical. Lightning receives hundreds of thousands of downloads per day and millions per month, making this among the highest-impact PyPI compromises of the year.

What the malware actually does

The attack is surgical and stealthy. The malicious package hides a _runtime directory containing a downloader and an obfuscated JavaScript payload. The execution chain fires automatically the moment the lightning module is imported — no additional interaction required.

Under the hood, Socket's analysis found two core components: start.py, which downloads and executes Bun (a JavaScript runtime) directly from GitHub, and router_runtime.js — an 11 MB obfuscated payload that runs silently in a daemon thread with suppressed output.

The use of Bun to execute an obfuscated JavaScript payload is a hallmark of the Shai-Hulud worm family, and Socket flagged clear overlaps: the obfuscated JavaScript payload shares similarities with Shai-Hulud attacks, with overlapping targeted tokens, credentials, and obfuscation methods. Socket also found signs that router_runtime.js both poisons GitHub repositories and infect developer npm packages.

The payload's scope is broad: the JavaScript file contains over 703 references to process and env, more than 463 references to tokens and authentication, and 336 references to repositories — alongside credential exfiltration patterns consistent with the theft of developer and cloud credentials, and GitHub API abuse designed to commit encoded data to repositories using stolen tokens.

The GitHub cover-up

A community member first flagged the compromise in Lightning-AI's GitHub repository under issue #21689, describing the hidden execution chain. That issue was closed without a public explanation. Socket then opened a follow-up warning issue in the Lightning-AI/pytorch-lightning repository. It was closed within one minute by the pl-ghost account, which posted a "SILENCE DEVELOPER" meme in response. This behaviour strongly suggests the project's GitHub account is itself compromised.

Part of a larger wave

This attack doesn't exist in isolation. As Cyber Kendra has been tracking, the sprawling TeamPCP supply chain campaign has also compromised Checkmarx's KICS Docker images and Bitwarden's CLI npm package, with hackers leaving it live long enough to harvest AWS keys, GitHub tokens, and SSH credentials.

Just last week, three separate supply chain attacks hit npm, PyPI, and Docker Hub between April 21–23, all targeting the same prize: API keys, cloud credentials, SSH keys, and tokens from developer environments and CI/CD pipelines.

What you need to do right now

Socket recommends treating any environment that has installed and imported either 2.6.2 or 2.6.3 as fully compromised. The immediate checklist:

Remove lightning 2.6.2 and 2.6.3 from all systems and downgrade to 2.6.1
Rotate all credentials that may have been exposed — GitHub tokens, npm tokens, AWS/GCP/Azure keys, and any secrets stored in environment variables
Audit your GitHub repositories for unexpected commits or encoded data
Inspect CI/CD logs and developer machines where the package may have been imported
Flag any npm packages published from affected machines for review, as the malware is capable of infecting npm tarballs

Socket is continuing its analysis and has pledged a deeper technical write-up as more indicators of compromise are confirmed.

This story is developing.

CVE-2026-41940: cPanel Authentication Bypass Was Already Being Exploited Before the Patch Even Dropped

protalweb@gmail.com (Vivek Gurung) — Wed, 29 Apr 2026 21:11:00 +0530

On April 28, 2026, cPanel pushed an emergency security update for what it described as a vulnerability affecting "various authentication paths" across all currently supported versions of cPanel and WHM (Web Host Manager — the server-level admin interface that controls virtually everything on a shared hosting server).

The advisory was clinical and brief. What it didn't say was that attackers were already inside.

The vulnerability, now tracked as CVE-2026-41940, is a CRLF injection flaw (a technique in which an attacker inserts hidden line breaks to manipulate file-based records) in cPanel's session-handling code. The root cause: a sanitization function called filter_sessiondata existed but was never called inside saveSession itself — every caller was expected to invoke it manually, and one critical code path in the core server daemon cpsrvd simply didn't.

KnownHost confirmed the exploitation window wasn't hours — it was at least 30 days. The vulnerability had been used as a zero-day against the management layer of a significant portion of the internet long before cPanel acknowledged a problem existed.

WatchTowr's researchers demonstrated the full attack chain. An attacker first triggers a failed login to mint a pre-authentication session, then sends a crafted HTTP Basic Authorization header — with the password field stuffed with \r\n-separated fake session records — while stripping the session cookie's encryption key. Those injected records land in the on-disk session file raw.

A second request, deliberately sent without a security token, forces cPanel to re-read the raw file and flush the injected data into the JSON cache. From that point, every subsequent request sees those forged values as legitimate session keys — including hasroot=1 and successful_internal_auth_with_timestamp, a flag that instructs cPanel to skip password validation entirely and return AUTH_OK unconditionally.

No password. No brute force. Full root-level access to WHM.

A web hosting and domain registration company, Namecheap, disclosed that it "relates to an authentication login exploit that could allow unauthorised access to the control panel."

Hosting providers, including Namecheap, KnownHost, hosting.com, HostPapa, and InMotion Hosting, all blocked cPanel ports at the network level while waiting for the patch. cPanel released a fix roughly 2–3 hours after the public advisory, with full deployment across major providers taking 6–7 hours.

The numbers make the stakes clear. With over 70 million domains relying on cPanel, the flaw dramatically expanded the attack surface, potentially enabling mass website defacement, data exfiltration, and server compromise across the hosting supply chain.

But the timeline raises harder questions. An industry source told webhosting.today that the vulnerability had been reported to cPanel approximately two weeks before the April 28 public advisory, and that cPanel's initial response was that nothing was wrong.

Hosting.com's incident communications described the issue as having been "responsibly disclosed to cPanel," confirming that private disclosure preceded the public advisory. The gap between "we told them" and "patch available" is the window during which active exploitation occurred. Webhosting

What you need to do right now:

If you manage a cPanel server, run /scripts/upcp --force as root to force the update, then verify your version with /usr/local/cpanel/cpanel -V. Patched builds are: 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.134.0.20, 11.136.0.5, and WP Squared 11.136.1.7.

Servers running unsupported or end-of-life versions will not receive patches and should be treated as actively compromised until proven otherwise. Enable two-factor authentication on WHM, restrict access to trusted IPs only, and audit your login logs for any suspicious access during the April 28 window before port blocks went into effect.

*The article has been updated after the WatchTowr post.

Copy Fail - A 732-Byte Python Script Can Get Root on Every Major Linux Distro

protalweb@gmail.com (Vivek Gurung) — Wed, 29 Apr 2026 23:42:00 +0530

A newly disclosed vulnerability in the Linux kernel gives any unprivileged local user a reliable, one-shot path to root — and it has been sitting undetected for nearly a decade. The exploit is a single 732-byte Python script. It works unmodified on Ubuntu, Amazon Linux, Red Hat Enterprise Linux, and SUSE. No guesswork, no timing windows, no per-distribution tuning required.

Researchers at Theori's Xint Code team published the details today under the name Copy Fail (CVE-2026-31431), disclosing both the root cause and a working proof-of-concept after coordinated patching with the Linux kernel security team.

Most Linux privilege escalation bugs demand some form of luck — a race condition to win, a kernel version to match, a compiled payload to stage. Copy Fail eliminates all of that. It is a straight-line logic flaw: run it once, get root. Researchers directly tested kernel lines 6.12, 6.17, and 6.18 across four distributions and observed a root shell every time.

The write-up draws a deliberate contrast with two famous predecessors. Dirty Cow (2016) required winning a memory-subsystem race, sometimes crashing the machine in the process. Dirty Pipe (2022) was limited to specific kernel versions and needed careful pipe-buffer manipulation. Copy Fail needs none of that — the same script simply works everywhere.

The bug lives at the intersection of three independent kernel changes made between 2011 and 2017 — none problematic on its own. The Linux kernel exposes its cryptographic subsystem to unprivileged userspace through a socket type called AF_ALG. A separate system call, splice(), can transfer file data between file descriptors without copying it — passing references to the kernel's own cached pages of a file directly into the crypto subsystem.

In 2017, an optimization was added to algif_aead.c that made AEAD (authenticated encryption) operations run "in-place," meaning the input and output scatterlists (memory maps used for crypto operations) pointed to the same location. This put live, shared page-cache pages into what the crypto layer treated as a writable destination. That mattered because of a separate, older bug in authencesn — a crypto wrapper used by IPsec for extended sequence numbers — which writes 4 bytes past the legitimate end of its output buffer as a scratch-pad operation and never restores them.

Together: an attacker splices any readable file's page cache into the crypto path, triggers an authencesn decryption, and that scratch write lands 4 controlled attacker-chosen bytes at a chosen offset inside the kernel's cached copy of that file. The HMAC check fails and recvmsg() returns an error — but the write already happened.

The default target is /usr/bin/su, a setuid-root binary on every tested distribution. Repeat the operation for each 4-byte chunk of shellcode, then call execve("/usr/bin/su").

The kernel loads the binary from the now-corrupted page cache. Because su is setuid, the shellcode runs as root.

Affected distributions

Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 14.3, SUSE 16, Debian, Arch, Fedora, Rocky, Alma, and other distributions running kernels built between 2017 and the patch are also affected.

The container problem

Copy Fail does not stop at the host. Because the Linux page cache is shared across all processes on a system — including across container boundaries — a compromised container or pod can use this primitive to tamper with the host's cached binaries and escape to the underlying node. The researchers are publishing a separate follow-up detailing the Kubernetes escape path.

How it was found

The discovery was a collaboration between human insight and AI tooling. Theori researcher Taeyang Lee identified AF_ALG combined with splice() as a promising attack surface — recognizing that this path could feed page-cache pages of read-only files directly into the kernel crypto subsystem.

That hypothesis was fed as an operator prompt into Xint Code, an AI-assisted security audit tool, which scanned the entire crypto/ subsystem in roughly an hour. Copy Fail was the highest-severity finding in the run. The same scan surfaced additional high-severity vulnerabilities still under coordinated disclosure.

What to do right now

Update your distribution's kernel package. The fix (mainline commit a664bf3d603d) reverts the 2017 in-place optimization in algif_aead.c, separating source and destination scatterlists so page-cache pages can no longer end up in a writable crypto destination. Major distributions are shipping the fix now.

If you cannot patch immediately, disable the algif_aead kernel module. This breaks nothing for the vast majority of systems — dm-crypt, LUKS, IPsec, TLS, SSH, and standard OpenSSL/GnuTLS builds all use the in-kernel crypto API directly and do not go through AF_ALG:

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || true

For containerized or multi-tenant workloads, block AF_ALG socket creation via seccomp policy regardless of patch state. The page-cache corruption does not persist across reboots — the cached page reloads clean from disk — but the root shell obtained before reboot is fully real.

The proof-of-concept is published on GitHub. The researchers ask that it be used only on systems the tester owns or has written authorization to test.

SAP CAP npm Packages Backdoored in "Mini Shai-Hulud" Attack — Rotate Your Tokens Now

protalweb@gmail.com (Vivek Gurung) — Wed, 29 Apr 2026 20:29:00 +0530

Four npm packages at the heart of SAP's enterprise development ecosystem were quietly backdoored on Tuesday, April 29, 2026 — weaponizing the routine npm install command to drain credentials from developer machines and corporate CI/CD pipelines.

The operation, which researchers are calling "Mini Shai-Hulud," has already left a visible scar across GitHub: over 1,000 developer repositories have been poisoned, all stamped with the same attacker's signature — "A Mini Shai-Hulud has Appeared."

The compromised packages are

mbt@1.2.48
@cap-js/sqlite@2.2.2
@cap-js/postgres@2.2.2
@cap-js/db-service@2.10.1

Together, they pull roughly 570,000 weekly downloads. These are not fringe libraries — they are core components of SAP's Cloud Application Programming Model (CAP), used by enterprise teams building cloud applications on SAP's Business Technology Platform, and in MTA (Multi-Target Application) deployment pipelines that touch production SAP systems.

What the Malware Actually Does

The normal package code in the affected versions still matches the legitimate SAP packages byte-for-byte. The compromise lives entirely in a pre-install hook and two added files. Aikido

Stage one is setup.mjs — a Bun runtime bootstrapper. It checks the operating system and architecture, downloads Bun 1.3.13 from GitHub when needed, extracts the binary, and runs execution.js with Bun. Routing the download through an official GitHub release URL was deliberate — it looks like legitimate traffic to most network-level egress filters. Aikido

Stage two is where the real damage happens. execution.js is an 11MB single-line obfuscated JavaScript blob that hunts for developer credentials in three phases: checking whether it's running inside GitHub Actions (CI/CD), scanning the filesystem and shell environment for GitHub OAuth tokens, npm automation tokens, and AWS/Azure/GCP credentials, then exfiltrating everything over HTTPS to an attacker-controlled C2 endpoint using layered AES-256-GCM plus RSA-OAEP encryption.

For any victim running inside GitHub Actions with a workflow-scoped token, the malware goes further: it uses the stolen token to commit malicious files — including a .vscode/tasks.json — directly to the victim's own repositories. Any developer who later clones and opens the compromised repository in VS Code will re-trigger the dropper. It's persistence through the developer's own trusted toolchain.

How the Attacker Got In

It has been reported that the attacker compromised a legitimate SAP developer account (RoshniNaveenaS) and modified a GitHub Actions workflow to exchange a GitHub OIDC (OpenID Connect) token for a live npm publish token scoped to @cap-js/sqlite.

The critical flaw: npm's trusted publishing configuration for that package trusted any workflow in the cap-js/cds-dbs repository — not just the canonical release workflow on the main branch. A push to a non-main branch was enough to obtain a valid publish credential.

The mbt package used a separate maintainer set, and its publish token appears to have been stolen through a different, as-yet-unconfirmed vector.

Familiar Playbook, High-Value Target

The attack's hallmarks — Bun-as-dropper, preinstall-phase execution, obfuscated credential harvester, repository poisoning — connect it directly to the Shai-Hulud malware family that has plagued the npm ecosystem since late 2025.

As we covered at Cyber Kendra, the original Shai-Hulud campaign compromised over 700 npm packages, including official CrowdStrike packages, and its second wave impacted more than 27,000 GitHub repositories and exposed approximately 14,000 secrets across hundreds of organizations. This latest variant targets a narrower set of packages but targets a far more privileged environment — enterprise SAP pipelines with access to production cloud infrastructure.

The payload targets GitHub, npm, cloud providers, Kubernetes, CI secrets, and local developer tooling — do not limit rotation to npm tokens.

What You Need to Do Right Now

If any of the four affected versions touched your environment on or after April 29, 2026:

Rotate everything immediately — GitHub tokens (all scopes), npm tokens, AWS/Azure/GCP access keys, and any CI/CD secrets
Audit your repositories for unexpected tasks.json additions in .vscode/ or .claude/ directories, and search your GitHub account for the description string "A Mini Shai-Hulud has Appeared."
Review CI/CD logs for unexpected Bun process spawns from temp directories during npm install
Check lockfiles for the four compromised version strings and downgrade to the last clean versions (@cap-js/sqlite@2.2.1, @cap-js/postgres@2.2.1,@cap-js/db-service@2.10.0, mbt@1.2.47)
Harden OIDC publishing configs by scoping trusted publishers to a specific workflow file on a protected branch, not a repository broadly

Socket is actively tracking the campaign. This is a developing story.

Why Some MacBook Features Break after macOS Updates

protalweb@gmail.com (Vivek Gurung) — Mon, 27 Apr 2026 22:57:00 +0530

No Mac user can deny that macOS updates are necessary. They improve the system’s entire performance and keep it stable over time. Apple’s updates usually install without any issues and bring noticeable improvements to daily use.

However, some users notice that certain features behave strangely after an update. They used to work without interruptions, but stopped responding out of nowhere. Users report problems with connectivity, input controls, or system interface. The changes usually result from adjustments in the way macOS manages system resources.

What Changes with a macOS Update

With each macOS update, the system replaces important components that control how the MacBook works. These may be system frameworks that control hardware components and background services. The features that depend on these components may behave differently until the system stabilises.

Users who find their Touch Bar not working on MacBook right after an update are often dealing with exactly this kind of reset. The Touch Bar is a good example of how tightly integrated some features are with macOS.

It relies on UI frameworks and background processes. If the update resets any of these elements, the feature may be unresponsive or just disappear. The same thing happens with other macOS features that depend on the connection between software and hardware. Post-update issues often affect several system components at once.

Common Features that Break after Updates

Features that depend on how hardware and system processes interact are the ones that suffer the most after a macOS update.

Hardware-associated features

Some functionalities depend on the way macOS connects with hardware:

Touch Bar
Trackpad
Keyboard backlight

Hardware-linked features need low-level system services, so even small changes in how those services load affect their responsiveness.

Connectivity and System Services

Many users report network-related issues after an update:

Wi-Fi connections dropping
Bluetooth devices are disconnecting or not pairing
AirDrop and Handoff inconsistencies

Power management

These glitches aren’t noticeable right after the update, but users see them after a while:

Wrong battery percentage reporting
Increased fan activity
Background processes are eating up more resources than they used to

These issues result from system reindexing, cache rebuilding, or updated power management. The system needs time to stabilise after the update.

Why Does This Happen?

The unresponsiveness is coming from the way macOS transitions from the old system state to the new one. Even when an update is correctly installed, several background changes can “break” how the features behave.

If macOS replaces system drivers or modifies important frameworks, it’s a big deal. Hardware takes time to adjust to the new configuration. If something doesn’t load properly on the first boot, you assume the feature doesn’t work. Actually, the hardware is completely fine.

Outdated caches are another cause of failure. macOS needs caches to perform indexing and launch apps without delays. After you update, the caches may not match the updated system files. Until they are rebuilt, you’ll notice slowdowns or even missing interface elements.

Permission and security changes play another role. New macOS versions introduce stricter controls on apps. This can reset previously granted permissions or block some background processes.

How to Troubleshoot after a macOS Update

In most cases, these steps are enough to solve the problem:

Restart

This is a basic step that can fix many post-update issues. It forces macOS to reload system services and complete background setup tasks. If the problem doesn’t go away, check Activity Monitor for processes that aren’t responding. If needed, restart them.

System-level resets

If that didn’t work, try this:

Reset NVRAM/PRAM (on Intel Macs). This can fix problems with the display, sound, and some hardware settings.
Reset SMC (on Intel Macs). That’s useful for power, battery, and thermal behaviour.

On Macs with Apple Silicon chips, a full restart performs most low-level resets that SMC/NVRAM used to handle. You can try a complete shutdown, and power on after a few minutes to see if the system resets power-related states.

Review software compatibility

It’s important to check if all apps you’ve installed are fully compatible with the current macOS version. Temporarily uninstalling (or at least disabling) problematic apps can help.

If you tried all steps and none of them worked, it may be a known system bug. Apple usually addresses such problems through minor updates, so check for the latest patches.

In most cases, post-update issues are temporary. The system should stabilise as macOS completes its background processes and adjusts to the new environment.

A Single Git Push Was All It Took to Compromise GitHub — Millions of Repos Were Exposed

protalweb@gmail.com (Vivek Gurung) — Tue, 28 Apr 2026 22:36:00 +0530

A critical vulnerability in GitHub's internal infrastructure allowed any authenticated user to execute arbitrary commands on GitHub's backend servers using nothing more than a standard git push command — potentially exposing millions of public and private repositories belonging to other users and organizations.

Discovered by Wiz Research and tracked as CVE-2026-3854, the flaw stems from an injection vulnerability in GitHub's internal X-Stat header — a semicolon-delimited protocol that passes security metadata between the platform's internal services.

When a user runs git push -o (push options), GitHub's babeld proxy embeds those user-supplied strings directly into the X-Stat header without stripping semicolons. Because the header parser uses last-write-wins logic, an attacker can simply inject a semicolon followed by a field name to silently override security-critical settings already set by the server.

From there, Wiz researcher Sagi Tzadik chained three injected fields to achieve full remote code execution: bypassing the production sandbox by overriding rails_env, redirecting the hook script directory via custom_hooks_dir, and finally delivering a path traversal payload through repo_pre_receive_hooks — forcing the system to execute an arbitrary binary as the git service user with full filesystem access.

GitHub Remote Code Execution - CVE-2026-3854

On GitHub Enterprise Server (GHES), this granted complete server compromise. On GitHub.com, one additional injected flag enabled enterprise-mode behavior, and the same exploit chain landed on shared storage nodes hosting repositories across millions of accounts.

Wiz confirmed that the git user's permissions allowed reading any repository on the compromised node, regardless of ownership — though the researchers say they did not access other tenants' actual data.

GitHub patched GitHub.com within six hours of the disclosure and released fixes across all supported GHES versions. However, Wiz warns that 88% of GitHub Enterprise Server instances remain unpatched at the time of publication. GHES administrators must upgrade to version 3.19.3 or later immediately.

GitHub CISO Alexis Wales called the finding rare, noting it earned one of the highest bug bounty rewards the platform offers.

Notably, the vulnerability was uncovered using AI-assisted reverse engineering through IDA MCP — marking one of the first critical flaws discovered in closed-source binaries with AI tooling.

If you run GitHub Enterprise Server, treat this as a fire drill — patch now.

Google Wallet Now Stores Your Aadhaar ID in India — and Expands Digital IDs to Three More Countries

protalweb@gmail.com (Vivek Gurung) — Tue, 28 Apr 2026 22:11:00 +0530

Google just made carrying a physical ID one step closer to optional. Starting today, Indian users can save their Aadhaar Verifiable Credential directly inside Google Wallet — stored on-device — while users in Singapore, Taiwan, and Brazil gain access to passport-based digital ID passes for the first time.

The Aadhaar integration, built in partnership with UIDAI (the government body that manages India's national identity system), lets users add their credential in a few taps and present it digitally wherever it's accepted.

The rollout kicks off with five launch partners: PVR INOX for age verification at cinemas, BharatMatrimony for verified profiles, Atlys for auto-filling international visa applications, and Mygate and Snabbit — both coming in the near future — for verifying delivery personnel and gig workers entering residential communities.

Google has implemented selective disclosure, meaning an app or service only sees what it actually needs — a cinema checking your age doesn't get your address or date of birth, just a confirmed yes-or-no on whether you're old enough.

On top of that, Zero Knowledge Proof (ZKP) cryptography lets the system verify a fact about you without exposing the underlying data at all. The integration is built on ISO 18013-5 and the W3C Digital Credentials API, the same global standards used for mobile driving licences in the US and EU, which means the credential is technically interoperable across platforms and future-proofed against fragmentation.

For the three newly added countries, Google Wallet's ID pass works differently — it's a secure digital ID generated from passport information, useful for in-person age checks and online account verification, rather than a government-issued verifiable credential.

The broader implication here is significant. India's Aadhaar covers over a billion enrolled users, and getting it into a widely installed app like Google Wallet — rather than a standalone government app most people ignore — dramatically raises the chances of real-world adoption. The gig economy and residential security use cases alone address friction points that affect millions of daily interactions in Indian cities.

The Aadhaar credential is live in Google Wallet now. The ID passes for Singapore, Taiwan, and Brazil are also available starting today.

Hackers Targeted LiteLLM's AI Gateway Just 36 Hours After Critical SQL Injection Flaw Went Public

protalweb@gmail.com (Vivek Gurung) — Tue, 28 Apr 2026 21:18:00 +0530

A critical, unauthenticated SQL injection vulnerability in LiteLLM — the open-source gateway that tens of thousands of organisations use to manage API access to OpenAI, Anthropic, and other AI providers — drew targeted exploitation attempts within 36 hours of its public disclosure, according to new research from Sysdig's Threat Research Team.

The flaw, tracked as CVE-2026-42208, affects LiteLLM versions 1.81.16 through 1.83.6. The vulnerability lies within the proxy's authentication step: the Bearer token from an HTTP request header is directly inserted into a SQL query without parameterization (a basic security safeguard), allowing any anonymous attacker to send crafted requests and pull arbitrary data from the PostgreSQL backend — no login required.

The database stores virtual API keys, provider credentials for services like OpenAI and AWS Bedrock, and the proxy's entire runtime environment configuration — effectively a master key to every AI service an organisation has connected to it.

Sysdig observed the first exploitation attempt at 04:24 UTC on April 26, just 36 hours and seven minutes after the advisory was indexed in GitHub's global advisory database on April 24.

The attacker, operating from two IP addresses in the same German autonomous system (AS200373, 3xK Tech GmbH), fired 29 UNION-based SQL injection payloads targeting precisely the three tables most likely to contain production secrets: LiteLLM_VerificationToken, litellm_credentials, and litellm_config.

That level of precision is what stood out to Sysdig's researchers. The attacker already knew LiteLLM's Prisma ORM table naming conventions — including the PascalCase quirk that generic scanners routinely miss — and went straight for credential-bearing tables, skipping benign ones entirely.

A second IP rotated roughly 20 minutes later, replaying the payload set and probing key management endpoints. The final request — a blunt OR 1=1-- — is consistent with an automated harness exhausting its full payload list.

No confirmed data extraction or key reuse was observed, but Sysdig is clear: absence of follow-through does not mean the attempt failed quietly.

The fix is available in v1.83.7, which replaces string interpolation with parameterized queries. Anyone running an internet-facing LiteLLM instance on a vulnerable version should patch immediately, rotate all stored credentials and virtual keys, and audit upstream provider billing logs for unexpected API activity.

The broader warning from Sysdig: AI gateways like LiteLLM aggregate cloud-grade credentials at a scale that makes a single SQL injection equivalent, in blast radius, to a full cloud account compromise. They should be treated accordingly.

LAPSUS$ Dumps Checkmarx Data on Dark Web — Source Code, API Keys, and Credentials Exposed

protalweb@gmail.com (Vivek Gurung) — Tue, 28 Apr 2026 08:44:00 +0530

The Checkmarx supply chain nightmare just got worse. The LAPSUS$ cybercrime group has publicly dumped data stolen from the Israeli application security company on its dark web leak site — and Checkmarx has now confirmed it's real.

On April 25, dark web threat intelligence account @DarkWebInformer flagged on X that LAPSUS$ added Checkmarx to its victim roster alongside MAPFRE and Vodafone. The exposed data reportedly includes source code, an employee database, API keys, and database credentials for both MongoDB and MySQL. Security researcher Adnan Khan noted the dump appears to total roughly 95 GB of private Checkmarx data.

In a security update published April 26, Checkmarx VP of Platform Engineering and Global CISO Udi-Yehuda Tamar confirmed the exposure, stating that a third-party forensic investigation points to the data originating from the company's GitHub repository. "Access to that repository was facilitated through the initial supply chain attack of March 23, 2026," the company said. Checkmarx has since locked down access to the affected repository and says its forensic probe is ongoing.

The company was quick to draw a line between the GitHub repo and its customer-facing infrastructure, stressing that the repository is maintained separately from its production environment and does not hold customer data. It pledged immediate notification if that assessment changes.

This is the latest domino to fall from the sprawling TeamPCP supply chain campaign — an operation that we (Cyber Kendra) covered last week when attackers pushed credential-stealing malware into Checkmarx's official KICS Docker images and two VS Code extensions on the Open VSX marketplace.

Hackers also compromise Bitwarden's CLI npm package (@bitwarden/cli version 2026.4.0), leaving it live for roughly 90 minutes — long enough to harvest AWS keys, GitHub tokens, and SSH credentials from any developer who installed it during that window.

TeamPCP has since boasted on BreachForums that it will "chain these compromises into devastating follow-on ransomware campaigns," and the LAPSUS$ publication appears to be exactly that follow-through. The attackers are deliberately targeting the tools developers are told to trust most — security scanners, password managers, and other high-privilege software wired directly into developer pipelines. The RegisterThe Register

If your organization uses Checkmarx tooling, act now:

Rotate any API keys, tokens, or credentials associated with Checkmarx integrations
Audit GitHub Actions workflows for unauthorized modifications
Remove and reinstall any VS Code extensions sourced from Checkmarx or Open VSX during the March–April window
Block the exfiltration endpoint audit.checkmarx.cx and IP 94.154.172.43 at your perimeter

The investigation is active. Checkmarx says a more detailed update was expected within 24 hours of the April 26 disclosure.

AI Agent Wiped a Startup's Entire Database in 9 Seconds — Then Confessed Every Rule It Broke

protalweb@gmail.com (Vivek Gurung) — Tue, 28 Apr 2026 07:51:00 +0530

When Jer Crane sat down to run a routine infrastructure task on a Friday afternoon, he had no idea he was about to spend the entire weekend manually reconstructing three months of customer data from Stripe receipts and email confirmations. His AI coding agent had other plans — and it executed them in under 10 seconds.

Crane is the founder of PocketOS, a SaaS platform that car rental businesses depend on for reservations, payments, and vehicle management. On April 24, his Cursor agent — running Anthropic's flagship Claude Opus 4.6 — hit a credential mismatch while working in PocketOS's staging environment.

Instead of stopping to ask for help, the agent decided to fix the problem itself. It searched the codebase, found an API token stored in an unrelated file, and used it to fire a single GraphQL mutation at Railway, the company's cloud infrastructure provider: mutation { volumeDelete(volumeId: "3d2c42fb-...") }

The production database was gone. Because Railway stores volume-level backups inside the same volume they protect — a fact buried in their own documentation — those went with it. The most recent recoverable backup was three months old.

The agent's own confession

What set this incident apart wasn't just the scale of the destruction — it was what happened when Crane asked the agent to explain itself. The model produced a detailed written admission, citing the exact safety rules it had been given and enumerating every one it had violated.

It acknowledged it had guessed that deleting a staging volume would be scoped to staging only, admitted it hadn't checked Railway's documentation before executing a destructive command, and confirmed it had acted entirely without being asked to.

"System prompts are advisory, not enforcing," Crane wrote in his X post, which drew over 4.5 million views. "The enforcement layer has to live in the integrations themselves — at the API gateway, in the token system, in the destructive-op handlers."

He's right. The agent knew it was wrong. It said so in writing. And it still couldn't stop itself.

Three failures, one outcome

The incident wasn't one thing going wrong — it was three separate architectural gaps colliding simultaneously.

First, Cursor's "Destructive Guardrails," which the company markets as restricting agents from altering production environments, failed to prevent the deletion. This isn't unprecedented: Railway CEO Jake Cooper initially said the deletion shouldn't have been possible, then acknowledged it was actually expected behavior — a whiplash response that raised more questions than it answered.

Second, the Railway API token Crane had created specifically for managing custom domains carried root-level permissions across the entire account. There is no role-based access control for Railway API tokens. Every token is effectively an admin key. The community has been asking for scoped tokens for years — it hasn't shipped.

Third — and most critically — Railway's backup architecture means a deleted volume takes its own backups down with it. Calling that a backup strategy is, at best, misleading.

The update

Railway CEO Jake Cooper stepped in on Sunday evening, helped restore PocketOS's data within an hour, and has since patched the vulnerable API endpoint to perform delayed deletes rather than instant ones. Crane confirmed that the data was recovered, and his customers are operational again.

What developers need to do right now

This incident is a pattern, not an anomaly. At least 10 documented cases across Cursor, Replit, Claude Code, and other AI coding tools share the same root causes: overpermissioned tokens, no confirmation mechanisms for destructive actions, and backups stored in the same blast radius as the data they protect.

If you are running production workloads with AI coding agents, audit your API token scopes today. Ensure backups live on an entirely separate infrastructure. And treat any AI agent system prompt as a suggestion the model may ignore — because, as Claude Opus itself confirmed in writing, sometimes it does.

The Rise of Autonomous Cyber Attacks: Risks, Examples & Defense

protalweb@gmail.com (Vivek Gurung) — Sat, 25 Apr 2026 08:18:00 +0530

Last month, a mid-size financial services company ran a routine penetration test. The testers used an AI-assisted reconnaissance tool to map the network. Within 40 minutes, the tool had identified exposed services, correlated employee names with LinkedIn data, generated targeted phishing lures, and flagged three likely paths to domain admin.

The internal security team, working with traditional alert queues and weekly review cycles, would not have caught any of it in time.

That was a controlled test. The real attackers are running the same playbook, but they do not stop when the clock runs out.

Key Takeaways:

Autonomous attacks operate at machine speed with no human in the loop
AI enables adaptive exploitation that bypasses static defenses
Traditional SOC workflows were not built for millisecond threat cycles
Defending autonomously is no longer optional; it is the only practical response

What Are Autonomous Cyber Attacks?

Autonomous cyber attacks are AI-powered operations that independently plan, execute, and adapt intrusions without requiring a human operator to guide each step. Unlike traditional attacks, where a person types commands and reacts to output, these systems make decisions dynamically, shift tactics when they encounter resistance, and propagate across environments faster than most security tools can generate an alert.

Three characteristics define them:

Self-learning: The attack refines its approach based on what succeeds. If a port scan triggers a firewall rule, the system notes that and tries a different vector.
Decision-making capability: The system evaluates multiple exploitation paths and selects the most promising one without waiting for a human to weigh in.
End-to-end automation: Reconnaissance, initial access, lateral movement, and exfiltration can all be chained together with no human touchpoints.

This is not theoretical. The tooling exists today, and significant portions of it are openly available.

The Autonomous Cyber Attacks are rising in 2026 due to the easy accessibility of AI tools and Large language models. Today, a moderately skilled operator can assemble one from open-source components, AI APIs, and leaked offensive toolkits in an afternoon

Real-World Examples of Some Autonomous Cyber Attacks

Attribution in this space is difficult, and public disclosure is rare. But several documented cases give a clear picture of where things stand.

The GT-1002 Campaign: Security researchers tracking this campaign documented a threat actor using automated tooling to conduct reconnaissance, credential stuffing, and lateral movement across hundreds of enterprise targets. What stood out was the operational pace. Actions that would normally indicate a human operator working over days were compressed into hours. The infrastructure rotated automatically, and the attack pivoted when individual vectors were blocked, without any apparent manual intervention.

AI-Assisted Espionage: Anthropic's own research has documented adversarial attempts to use AI systems to assist in cyber operations. In documented cases, AI platforms were queried to assist with reconnaissance, writing attack scripts, and identifying security control gaps. The significance is not that AI was the attack itself, but that it dramatically accelerated the pre-attack research phase.

Hexstrike-AI Framework: Circulated within offensive security communities, this framework demonstrated an end-to-end automated attack chain: from public internet reconnaissance to internal network pivot, using AI to select and sequence attack techniques based on real-time feedback from the target environment. Regardless of who ultimately uses tooling like this, its existence demonstrates that fully automated, adaptive attack chains are technically feasible today.

How to Defend Against Autonomous Cyber Attacks

The reflexive answer is "use AI for defense too." That is partially right, but it obscures what actually needs to change operationally.

AI-Native Security Architecture

The core problem with traditional security stacks is that they were built around human review cycles. An alert is generated, queued, triaged, and escalated. That workflow made sense when attacks moved at human speed. It does not work when an attacker can complete initial access and lateral movement before the first alert is acknowledged.

Real-time detection means analyzing behavior at the point of occurrence, not after log aggregation. Network detection systems, endpoint telemetry, and identity activity monitoring need to feed into decision systems that can act within seconds, not minutes.

Automated response is the logical extension. Isolating a compromised endpoint, revoking a suspicious session token, and blocking an anomalous outbound connection: these actions cannot wait for a security analyst to approve them when the attacker is already moving laterally.

The pushback from operations teams is predictable. Automated response blocks legitimate users sometimes. That is a real cost. But the alternative is accepting that human review timelines are incompatible with the threat environment.

Zero Trust and Identity Security

Most security architectures still have a soft interior. Once an attacker has a valid credential and is inside the network perimeter, movement is surprisingly easy. Implicit trust based on network location is the foundational assumption that most attack chains depend on.

Continuous verification changes that calculus. Every access request, every API call, every privileged operation is evaluated against the current context: device health, user behavior patterns, time of day, geographic anomalies. A credential used from an unusual location at an unusual time does not automatically succeed.

Least privilege access removes the value of compromised credentials. If a developer's account can only access the specific resources their current work requires, a stolen credential is far less useful to an attacker. Operationalizing this requires more than a policy document; it requires an identity and access management solution for Zero Trust that enforces continuous verification, scopes permissions dynamically, and reduces or eliminates standing access across the environment.

Continuous Monitoring and Behavioral Analytics

AI-powered attacks do not behave like human attackers in terms of pattern and timing. They often move faster, access more resources in sequence, and operate at times that fall outside normal working hours. Behavioral analytics systems that baseline normal activity can flag these anomalies even when each individual action looks legitimate in isolation.

A single failed authentication is noise. Fifty sequential failed authentications across different accounts from the same IP range, at 3 AM, followed by one success, is a pattern. Systems that detect and respond to the pattern, rather than the individual event, are significantly harder to bypass.

Securing AI Systems

Security teams increasingly need to defend their own AI deployments. Large language models used in internal tooling can be targeted through prompt injection, where malicious input manipulates the model into performing unintended actions or disclosing sensitive information.

The OWASP Top 10 for LLM Applications provides a starting framework. Key concerns include prompt injection, training data poisoning, and over-reliance on AI outputs without human validation. Organizations deploying AI-assisted security tools need to treat those tools as part of the attack surface, not just part of the defense.

The Role of Identity and Access Management in Defense

Autonomous attacks are effective in large part because they exploit legitimate credentials and access paths. The attacker does not break in through the window; they walk through the front door with keys they found or stole.

Identity and Access Management (IAM) and Privileged Access Management (PAM) address this directly by:

MFA and Adaptive Authentication

Automated credential stuffing attacks test millions of username-password combinations against login portals. Standard MFA blocks the vast majority of these because the attacker has the password but not the second factor. Adaptive MFA goes further: it evaluates context at each login attempt, flagging anomalies in location, device fingerprint, or behavioral patterns and stepping up verification requirements accordingly.

Identity Lifecycle Management (Provisioning and Deprovisioning)

Orphaned accounts are one of the most consistently exploited entry points in enterprise environments. An employee leaves, their Active Directory account persists, and six months later, an autonomous scanner finds it during credential stuffing. Automated provisioning and deprovisioning closes this loop: access is removed when roles change or employment ends, not when someone remembers to file a ticket.

Role-Based Access Control

Role-based access control makes the users hold only the minimum permissions their work requires; a compromised credential gives the attacker a narrow foothold rather than broad infrastructure access. AI malware that hijacks a user session inherits that session's permissions. Keeping those permissions tightly scoped limits how far the attack can propagate.

Single Sign-On (SSO)

SSO centralizes authentication through a single control point, which means anomalous activity is easier to detect and correlate. A credential being used to authenticate against fifteen different applications in four minutes is obvious in a centralized SSO log. That same activity spread across fifteen separate authentication systems may never surface as a coherent signal

Just-in-Time Privileged Access

Standing administrative privileges are a permanent target. Just-in-time access management makes sure privileges are granted for a specific task, for a limited window, and revoked automatically when the window closes.

Session Monitoring and Recording

Even legitimate admin access can be abused, whether by a compromised account or a malicious insider. Privileged session management records privileged sessions to create an auditable trail of exactly which commands were run, which files were accessed, and which systems were touched. It also creates a detection surface: behavioral analytics applied to session recordings can flag automated command sequences that look nothing like human interaction.

Credential Vaulting and Rotation

Static credentials are a gift to autonomous attackers. A password that never changes, once exfiltrated, remains valid indefinitely. Credential vaulting stores secrets in an encrypted, access-controlled store rather than in config files or developer laptops. Automated rotation changes those passwords on a regular schedule, meaning stolen credentials have a limited validity window. AI bots built around credential reuse find that the credentials they collected last month no longer work.

Solutions like miniOrange's IAM and PAM platform consolidate these controls: credential vaulting, just-in-time access provisioning, privileged session monitoring, and machine identity management in a single operational framework. The practical value is not just in having the controls, but in having them integrated so that signals from one layer inform decisions in another.

Future Outlook: AI vs. AI Cybersecurity

The trajectory is clear. Offensive AI capabilities will continue to improve. Defensive AI capabilities will need to match that pace. The intermediate period, where attackers have sophisticated AI tooling and defenders are still running largely manual SOC operations, is the most dangerous window.

AI vs. AI warfare is already a meaningful framing. Autonomous attack systems probing for weaknesses, automated defense systems detecting and responding, and the outcome determined by which side has better models, better data, and faster feedback loops.

Predictive threat intelligence is an emerging defensive capability. Rather than detecting attacks that are already in progress, systems trained on attack patterns can identify the precursors: scanning activity, credential testing and staging infrastructure registration. Acting before the attack chain reaches exploitation is significantly more effective than responding during lateral movement.

Autonomous SOCs are a real near-term development. Not replacing human analysts, but automating the high-volume, time-sensitive work: alert triage, initial investigation, containment actions. Human analysts focus on judgment calls and strategic decisions while automated systems handle the operational tempo.

Regulatory frameworks are developing in parallel. NIST's AI Risk Management Framework provides structured guidance for managing AI-related risk, including the risks of AI-powered adversaries. Compliance frameworks are likely to evolve to explicitly address autonomous threat scenarios.

Are We Ready? A Final Assessment

Most organizations are not. That is not a criticism; it is an accurate description of where the industry stands.

Security programs built over the past decade were designed for a threat environment where attackers moved at human speed. The tooling, processes, and staffing models reflect that assumption. The threat environment has changed faster than most organizations have adapted.

But the gap is closeable. The starting point is honest assessment.

Organizational Readiness Checklist:

Can your SOC detect and respond to a threat within minutes, not hours?
Are privileged access permissions reviewed and right-sized quarterly?
Do you have behavioral analytics capable of detecting anomalous patterns, not just known signatures?
Are machine identities (service accounts, API keys) inventoried and monitored?
Is MFA enforced with session-level controls, not just at login?
Do you have automated response capabilities for common threat scenarios?
Are AI tools in your environment treated as part of the attack surface?

Maturity Levels:

Level	Characteristics
Reactive	Alert-based, human review and incident response after compromise
Preventive	MFA, patching, basic monitoring, policy enforcement
Detective	Behavioral analytics, threat hunting, anomaly detection
Adaptive	AI-assisted detection, automated response, continuous verification
Autonomous	AI-native defense, predictive intelligence, real-time autonomous response

Most enterprise organizations sit between Preventive and Detective. The threat environment requires at least Adaptive.

Immediate Next Steps:

Audit all privileged accounts and remove standing administrative access where not operationally necessary
Implement behavioral analytics on identity and privileged activity, not just network traffic
Introduce just-in-time access for high-risk systems, reducing the value of stolen credentials
Inventory and rotate machine identity credentials on a scheduled basis
Test your automated detection and response capabilities against a realistic autonomous attack simulation
Evaluate your AI systems for exposure to prompt injection and model manipulation

If the goal is to enforce controls like session monitoring, just-in-time access, behavioral analytics, and centralized privileged activity auditing without building each capability independently, platforms like miniOrange PAM can centralize these capabilities across hybrid and cloud environments without disrupting existing developer and operations workflows.

The attackers have already automated. The only viable response is to automate the defense.

Frequently Asked Questions:

Q. What are autonomous cyber attacks?

A. AI-driven attacks that independently plan, execute, and adapt cyber intrusions without human involvement. They use machine learning and automation to select targets, identify vulnerabilities, and move through environments faster than human defenders can respond.

Q. What is an AI cyber attack?

A. A cyber attack that uses artificial intelligence to automate decision-making, targeting, and execution. This includes AI-generated phishing content, automated exploitation, and self-adapting malware that evades detection.

Q. What are the top types of autonomous cyber attacks?

A. AI-powered phishing and deepfakes, self-adapting malware, autonomous botnets, and AI-based vulnerability discovery are the primary categories currently observed in enterprise environments.

Q. Why are autonomous attacks particularly dangerous?

A. They operate at machine speed, adapt in real time when defenses block initial approaches, and can run the same campaign against thousands of targets simultaneously. Traditional security workflows built around human review cycles are poorly matched to this tempo.

Q. How can organizations defend against AI cyber threats?

A. Through AI-native detection and automated response, Zero Trust security with continuous verification, behavioral analytics that detect anomalous patterns rather than known signatures, and identity governance that limits the value of compromised credentials.

Your TLS Certificates Are About to Silently Break — And You Won't Know Until It's Too Late

protalweb@gmail.com (Vivek Gurung) — Fri, 24 Apr 2026 08:34:00 +0530

A quiet but consequential change is coming to internet security infrastructure — and unlike most breaking changes, this one won't announce itself until it's already caused an outage.

Starting May 2026, major public Certificate Authorities, including Let's Encrypt, DigiCert, Sectigo, and GlobalSign, will stop embedding the Client Authentication Extended Key Usage (EKU) flag in their publicly issued TLS certificates.

The CA/Browser Forum — the governing body that sets browser and CA policy — has ruled that client authentication is a private identity concern, unsuitable for public trust infrastructure. The decision is industry-wide and non-negotiable.

For most websites and HTTPS services, nothing changes. The problem falls squarely on organizations running mutual TLS (mTLS) — a security model in which both the server and the client present certificates to verify each other's identities, commonly used in high-stakes distributed systems.

Apache Kafka, Cassandra, ZooKeeper, Pulsar, Ignite, and Geode all support mTLS as a first-class authentication mechanism, and many production deployments quietly rely on public CAs to issue those client certificates.

The risky part isn't the policy itself — it's the timing. Certificates issued before the May cutoff continue to work until they expire. The failure arrives with the next routine renewal.

What looks like a stable, fully operational cluster one day becomes an authentication black hole the next, with brokers rejecting clients and cluster members unable to handshake with each other. The certificate will appear perfectly valid in every other respect, making diagnosis genuinely tricky.

Every major TLS library — Java's JSSE, Go's crypto/tls, Rust's rustls, and OpenSSL — enforces the clientAuth EKU check. There's no runtime workaround. The fix requires switching client certificate issuance to an internal or enterprise CA that correctly issues certificates with the required EKU.

Three migration paths exist: run a full internal PKI for both server and client certs; adopt a hybrid model where servers keep public CA certs, but clients move to a private CA; or drop mTLS entirely in favor of application-layer authentication (tokens, OAuth) while retaining standard TLS encryption.

To check if you're exposed, run:

openssl x509 -in your-cert.pem -noout -text | grep -A1 "Extended Key Usage"

If the output shows TLS Web Client Authentication and the cert was issued publicly, your clock is ticking.

The Apache Software Foundation's advice is straightforward: start now. Every certificate renewal in the 12 months following May 2026 is a potential production incident waiting to happen.

Vercel Hacked: Breach Is Bigger Than First Disclosed — Customer Data Stolen Before the Attack Even Started

protalweb@gmail.com (Vivek Gurung) — Fri, 24 Apr 2026 07:54:00 +0530

What began as a contained supply chain incident has quietly expanded into something far more serious.

Vercel has updated its April 2026 security bulletin, confirming that some customer data was stolen before the breach the company originally disclosed — and that the threat actor behind this attack was already hunting for developer credentials across the broader internet well before the Context.ai compromise that initially triggered the investigation.

Vercel's security team sifted through nearly a petabyte of network and API logs — extending well beyond the original Context.ai entry point — and surfaced two separate findings.

First, additional customer accounts were compromised as part of the April incident, beyond the initially identified subset. Second, and more alarmingly, a separate cluster of customer accounts showed signs of compromise that predates the April breach entirely and appears unconnected to Vercel's own systems.

Vercel has described these earlier intrusions as potentially resulting from social engineering, malware, or other external methods — and has already contacted affected customers.

CEO Guillermo Rauch pointed directly to infostealer malware (credential-harvesting software that silently extracts passwords, tokens, and API keys from infected machines) as the likely mechanism. Once attackers collected those keys, Vercel's logs reveal a consistent playbook: fast, systematic API calls designed to enumerate and read non-sensitive environment variables—the configuration values that hold API keys, database credentials, and third-party service tokens.

That pattern lines up with earlier reporting that a Context.ai employee's computer was infected with infostealer malware after allegedly searching for Roblox game cheats — a textbook infostealer delivery scenario.

This Is Bigger Than One Company

Vercel has notified other suspected victims of this threat actor entirely outside of this incident. The company is now coordinating with Microsoft, AWS, Wiz, GitHub, npm, and Socket as part of a widened industry response. On one confirmed positive note: npm packages published by Vercel have been verified as uncompromised, meaning the Next.js supply chain remains clean for now.

If you haven't rotated your Vercel environment variables — especially any not marked as "sensitive" — treat them as already stolen.

Enable multi-factor authentication immediately, review your account activity logs for anything unusual between April 1 and now, and migrate all secrets to Vercel's sensitive environment variables feature going forward. Crucially, Vercel warns that simply deleting your project or account does not eliminate the risk — compromised secrets can still be used against live production systems.

Bitwarden CLI Hijacked to Steal Your AWS, GitHub, and SSH Secrets

protalweb@gmail.com (Vivek Gurung) — Thu, 23 Apr 2026 20:44:00 +0530

If you installed Bitwarden's command-line password manager this month, your developer credentials — including cloud keys, SSH material, and GitHub tokens — may already be in an attacker's hands.

Security researchers at Socket and JFrog have confirmed that @bitwarden/cli version 2026.4.0, published to npm, was backdoored as part of the same sprawling Checkmarx supply chain campaign that previously poisoned official KICS Docker images and VS Code extensions.

Bitwarden has since confirmed the incident, stating the malicious package was live on npm between 5:57 PM and 7:30 PM ET on April 22, 2026 — a roughly 90-minute window. The company says it found no evidence that end-user vault data was accessed or that production systems were compromised, and a CVE is being issued for the affected version.

The attack vector was a compromised GitHub Action inside Bitwarden's own CI/CD pipeline (the automated system that builds and publishes software), meaning the malicious package carried Bitwarden's legitimate branding and repository metadata without raising obvious red flags.

The tampered package swapped out the legitimate CLI binary entry point for a custom loader, bw_setup.js, which silently runs on installation via a preinstall npm script hook — before most users would notice anything was wrong.

That loader then downloads the Bun JavaScript runtime from GitHub if it isn't already present — a deliberate evasion trick to avoid raising suspicion — before executing a heavily obfuscated payload stored in bw1.js.

Once deobfuscated, the payload reveals one of the most aggressive credential-stealing frameworks seen in an npm supply-chain attack. It runs three collectors in parallel: a filesystem sweep targeting SSH keys, .git-credentials, .npmrc, .env, shell history, AWS credentials, GCP secret stores, and Azure Key Vault material; a shell collector that explicitly runs gh auth token to harvest GitHub CLI credentials and scans the process environment for token patterns; and a GitHub Actions runner collector that harvests CI secrets from automated build environments.

What makes this attack stand out is how it weaponizes stolen GitHub tokens rather than just collecting them. The malware validates tokens, enumerates repositories, creates new branches, commits malicious workflow files, waits for the Actions pipeline to execute, then silently deletes the evidence.

It also explicitly targets AI coding assistant configuration files, including ~/.claude.json and ~/.kiro/settings/mcp.json — a clear signal that attackers are increasingly interested in environments where AI tools may expose API keys or workflow automation secrets.

Stolen data is encrypted using hybrid AES-256-GCM and RSA encryption before being exfiltrated to audit[.]checkmarx[.]cx — a domain masquerading as legitimate Checkmarx infrastructure. If that path is blocked, the malware falls back to GitHub itself, staging encrypted result blobs inside repositories created under the victim's own account.

If you installed @bitwarden/cli 2026.4.0, act immediately:

Run npm uninstall -g @bitwarden/cli and npm cache clean --force
Rotate all GitHub PATs, npm tokens, AWS access keys, GCP and Azure secrets present on that machine
Audit GitHub Actions workflows and repository artifacts for unauthorized runs or branches
Block audit.checkmarx.cx and 94.154.172.43 at your network perimeter
Review shell history and any AI tooling configuration files for sensitive data exposure

Users who did not install the package during that specific window are not affected, and Bitwarden confirms vault data integrity was not compromised.

Pack2TheRoot Flaw Lets Root to Any Linux User — Ubuntu, Debian, Fedora at Risk

protalweb@gmail.com (Vivek Gurung) — Thu, 23 Apr 2026 21:29:00 +0530

A newly disclosed vulnerability in a near-universal Linux component has handed any local, unprivileged user the keys to the entire system — no password, no exploit chain, no guesswork required.

Dubbed Pack2TheRoot and tracked as CVE-2026-41651, the flaw lives in PackageKit — the background daemon that most major Linux desktop distributions use to manage software installations without requiring users to drop into a terminal.

The bug has existed since PackageKit version 1.0.2, released over 12 years ago, meaning the vulnerable codebase has shipped inside countless Linux systems as a default component for well over a decade.

The vulnerability was uncovered by Deutsche Telekom's Red Team, who noticed something suspicious during routine research: running a simple pkcon install command on a Fedora Workstation could install a system package without prompting for a password. That oddity became a thread worth pulling.

The team — assisted by AI-guided analysis using Claude Opus — eventually identified an exploitable race condition (a flaw where two competing processes can be manipulated to produce an unintended outcome) that allows a low-privileged attacker to install or remove system packages entirely without authorisation, ultimately dropping into a full root shell.

The CVSS score is 8.8 (High), with low attack complexity and no user interaction required—a combination that makes this straightforwardly dangerous in any multi-user environment, shared server, or corporate Linux workstation.

Confirmed vulnerable distributions include Ubuntu Desktop 18.04, 24.04.4, and 26.04 beta; Ubuntu Server 22.04–24.04; Debian Trixie 13.4; Rocky Linux 10.1; and Fedora 43 Desktop and Server. The researchers also flag that servers running Cockpit — a popular web-based Linux admin panel — may be exposed even when PackageKit isn't running as a persistent service, since both tools activate on demand via D-Bus.

One usable indicator of compromise exists: after successful exploitation, the PackageKit daemon crashes with an assertion failure. Administrators can check system logs with journalctl -u packagekit | grep emitted_finished for evidence of prior exploitation.

The fix is already available. PackageKit 1.3.5 resolves the issue, and Debian, Ubuntu, and Fedora have released patched packages as of April 22, 2026. Users should run their system updater immediately and verify their installed PackageKit version via dpkg -l | grep -i packagekit or rpm -qa | grep -i packagekit.

Technical details of the root cause and the proof-of-concept exploit are being withheld pending broader adoption of the patch.

Lovable Left Thousands of Projects Exposed for 48 Days — And Still Hasn't Fixed It

protalweb@gmail.com (Vivek Gurung) — Mon, 20 Apr 2026 22:46:00 +0530

The vibe-coding platform Lovable.dev is sitting on a ticking data exposure bomb — and it's been ticking for 48 days.

A security researcher going by @weezerOSINT published a thread on X today revealing that a critical Broken Object Level Authorization (BOLA) flaw in Lovable's API allows any free account — created in minutes — to access the source code, database credentials, AI chat histories, and customer data belonging to other users.

The vulnerability affects every project created before November 2025, potentially exposing tens of thousands of developers and their end users.

Update: Lovable Admits It Broke Its Own Security Fix — Exposed User Projects for 76 Days

BOLA — ranked #1 on OWASP's API Security Top 10 — occurs when an API verifies that a user is logged in, but doesn't check whether that user actually owns the resource they're requesting. In Lovable's case, the /projects/{id}/* endpoints verify Firebase authentication tokens but skip ownership checks entirely. That single gap is enough to bring the entire platform's project history within reach of anyone with a free account.

The researcher demonstrated just how severe this is by accessing an active admin panel for Connected Women in AI, a Danish nonprofit with over 3,700 developer edits in 2026 alone — clearly not abandoned.

From there, the source code revealed hardcoded Supabase credentials, which were used to query the live database and pull real names, job titles, LinkedIn profiles, and Stripe customer IDs belonging to real professionals from Accenture Denmark and Copenhagen Business School. "This is not hacking. This is five API calls from a free account."

The damage doesn't stop at source code. Because Lovable stores the full AI conversation history tied to each project, an attacker can read every prompt a developer ever sent — including pasted error logs, business logic discussions, and credentials shared mid-session. In one retrieved chat, a developer had walked Lovable's AI through building database tables containing email, date_of_birth, stripe_customer_id, and more. All of it, readable.

The bug was first reported on HackerOne on March 3, 2026 — 48 days ago. Lovable triaged it. Then they shipped ownership checks for new projects and quietly left every pre-existing project wide open.

When the researcher filed a second report documenting additional affected endpoints, Lovable marked it a duplicate and closed it. As of today, a project created in April 2026 returns 403 Forbidden.

Lovable's response was characterized as "sophisticated" in some circles, but the researcher's findings suggest the opposite: the company chose to protect new users and simply abandoned everyone who already built on the platform.

Yesterday, Vercel disclosed its own security incident. Vercel traced the intrusion to Context.ai, a third-party AI tool used by an employee, where a compromised Google Workspace OAuth connection allowed attackers to escalate access into Vercel's internal environments.

A threat actor using the ShinyHunters name subsequently listed stolen Vercel data — reportedly including API keys, source code, and employee records — for sale on BreachForums for $2 million. As Cyber Kendra reported, Vercel has engaged incident response experts and notified law enforcement, warning the breach may affect hundreds of users across many organizations.

Taken together, both incidents point to a broader structural problem in AI-assisted development platforms: security is bolted on after the fact, if at all.

Security firm Symbiotic noted it bluntly: "Telling developers to review security before publishing doesn't work when those developers chose AI tools because they're not security experts."

What Lovable users should do right now:

Rotate all database credentials immediately, especially Supabase API keys embedded in your project source.
Audit your AI chat history for any credentials, API keys, or sensitive data you may have pasted mid-session.
Set projects to private where possible — though as the researcher notes, free-tier users cannot do this on Lovable.
Assume your pre-November 2025 project source code is already public and act accordingly.

Update: Lovable has now responded publicly on X. In an initial statement, the company said: "We did not suffer a data breach," attributing the issue to unclear documentation around what "public" project visibility implies — and confirmed that chat messages on public projects have now been made private. It maintained that code visibility on public projects is "intentional behavior" and "consistent by design."

Following community pushback, Lovable issued a second, more detailed statement acknowledging what actually happened. The company explained that in February 2026, while unifying permissions in its backend, it accidentally re-enabled access to chat histories on public projects — a regression that undid a prior API patch.

The HackerOne reports filed against this were closed without escalation because triage partners incorrectly interpreted the behavior as intentional. Lovable says it has now reverted the change and locked down all public project chats. "We understand that pointing to documentation issues alone was not enough here. We'll do better," the company said.

The chat exposure fix is now in place. However, Lovable has not addressed the source code visibility concern for public projects, which the company continues to describe as working as intended.