April 2026 Cybersecurity: Red-Team Analysis for Companies


April 2026 was a month when cybersecurity left the slide deck and showed up in the daily tools companies rely on. Not through one spectacular breach, but through a chain of smaller technical failures that make perfect sense from an attacker’s point of view. Linux privilege escalation. Compromised npm packages. An AI gateway holding provider keys. A developer platform processing trusted code. OAuth permissions that looked like a harmless productivity integration.

For Haxoris, this is exactly the kind of material that matters in red teaming, penetration testing and attack surface reviews. The real question is not only whether another vulnerability exists. The question is how it connects to cloud security, CI/CD security, identity and access management, AI security, incident response and cyber resilience. April showed that modern attacks rarely start like movie scenes. They start inside normal business workflows that were never designed to carry this much trust.

For companies working on NIS2, ISO 27001, DORA, Zero Trust, DevSecOps, cloud security or AI security, April was a useful stress test of real operations. Not the policy version, but the version that runs on laptops, build pipelines, SaaS integrations, tokens and admin panels. That is where small assumptions turn into real incidents.

29 April

Copy Fail: when a weak local account becomes root

Xint Code Research Team disclosed Copy Fail, tracked as CVE-2026-31431. It is a logic flaw in the Linux kernel, specifically in the authencesn cryptographic template. An unprivileged local user can trigger a controlled four-byte write into the page cache of a readable file.

The researchers showed that a short proof-of-concept Python script can modify a setuid binary only in memory and obtain root privileges. Major distributions including Ubuntu, Amazon Linux, RHEL and SUSE were tested.

The most interesting part is not only the privilege escalation itself. The write does not look like a normal file modification on disk. The corrupted page is not marked for write-back, so the file on disk can still appear unchanged while the in-memory version behaves differently. A routine checksum comparison may therefore show nothing suspicious.

In offensive security testing, this is exactly the kind of bug that turns limited access into control of the system. An attacker does not need to start as an administrator. A compromised user account, a web shell, a weak service account or access to a container can be enough. Local privilege escalation then becomes the bridge between the first foothold and host takeover.

The container angle is also important. The page cache is shared by processes on the host system, and according to Xint, the impact reaches across container boundaries. That does not mean every container collapses with one command. It does mean that “it only runs in a container” is not a security strategy.

Mini Shai-Hulud: when a normal dependency install starts collecting credentials

Wiz published an analysis of the Mini Shai-Hulud campaign. It affected legitimate SAP ecosystem packages in the npm registry. Attackers inserted a malicious pre-install script into packages such as @cap-js/sqlite, @cap-js/postgres, @cap-js/db-service and mbt, causing the script to execute automatically during routine dependency installation.

That is the key point. The developer did not have to do anything strange. They did not download pirated software, open a suspicious attachment or click on a fake login page. They did exactly what developers do every day: installed dependencies and built a project.

According to Wiz, the malicious code downloaded the Bun runtime and then executed a credential stealer. It targeted GitHub tokens, npm credentials, AWS, Azure and GCP cloud secrets, Kubernetes tokens and secrets used in GitHub Actions. The data was exfiltrated through attacker-controlled GitHub repositories, and the malware also included logic for further propagation using compromised tokens.

For companies, this is a very practical lesson. Build and deployment automation is not a side tool. It is often the environment that holds some of the most valuable access in the company. It can reach source code, container registries, cloud environments, Kubernetes clusters, production deployments and sometimes customer data.

The question is not only “are we using safe packages?” The better question is: if a malicious package runs inside your build process, what can it read? If the answer is “almost everything”, then the problem is not only the package. The problem is that the automation has more trust than it actually needs.

LiteLLM: an AI gateway as a vault for other people’s keys

LiteLLM handled a critical vulnerability tracked as CVE-2026-42208. The Belgian Centre for Cybersecurity described the risk directly: LiteLLM acts as an AI gateway that centralizes credentials for providers such as OpenAI or Anthropic. Successful exploitation could therefore mean losing access to all connected AI provider accounts at once.

The technical cause was unpleasantly simple. The value of an access token from an HTTP request could reach a database query without sufficient sanitization. An attacker could therefore act before authentication and access stored application keys, provider credentials and other sensitive data in the database.

This matters to every company adopting AI. A gateway like this is not an experimental tool at the edge of infrastructure. Very quickly, it becomes a central store for application keys, billing identities, usage rules, request logs and sometimes internal data.

In an offensive assessment, this kind of component would attract attention immediately. Not because AI is fashionable, but because new tools are often deployed faster than their security model is defined. Where are the keys stored? Who can read them? What is logged? Can access be revoked quickly? Does every provider have its own account and spending limit? These answers decide whether an incident stays local or turns into a broader cloud and AI compromise.

28 April

GitHub: even a routine developer command can become a server-side problem

GitHub published a write-up of a critical vulnerability in the infrastructure that processes git push. The issue was reported by researchers from Wiz through GitHub’s bug bounty program. GitHub said it reproduced the issue internally within 40 minutes, fixed it on GitHub.com in less than two hours and found no evidence of exploitation in its forensic review.

The impact was serious. A user with permission to push to a repository, including a repository they created themselves, could cause command execution on the server processing the push. A specially crafted push option using insufficiently sanitized input was enough.

For companies, the wider lesson is more important than the specific bug. GitHub, GitLab, Bitbucket and internal code repositories are no longer just places to store source code. They are hubs where identity, automation, approvals, secrets, builds, tests, deployments and audit trails meet.

The offensive question is: what happens in your company after a successful push? Does a build start? Are sensitive variables loaded? Is an artifact created? Is code deployed to the cloud? Does the build runner have production access? Every one of those answers turns an ordinary developer action into a security decision.

cPanel and WHM: the administration panel as keys to several doors

cPanel released fixes for CVE-2026-41940, an authentication bypass in the WHM API. After updating only the wp-toolkit-cpanel package, an unprivileged user could call the WHM API in a way that bypassed intended access controls. The vendor rated the issue as critical.

This is not a glamorous topic, which is exactly why it matters. Hosting panels, administration consoles and customer portals often sit quietly at the edge of environments for years. They are rarely the star of a security presentation, but they can manage domains, mailboxes, databases, websites, backups, certificates and user accounts.

If an attacker gains access to that layer, they do not need an exotic exploit in the main application. They can create a mailbox, change a website, download data, add a user, prepare a phishing page on a legitimate domain or look for configuration files containing credentials.

From the Haxoris point of view, management panels are part of the perimeter. They deserve the same attention as VPN, remote administration and cloud consoles: multi-factor authentication, strict exposure rules, updates, logging and ownership. The question “who actually owns this panel?” should never be answered only after an incident.

24 April

UNC6692: fake support, Teams and a malicious browser extension

Google Cloud’s Mandiant team described activity by UNC6692, a financially motivated actor using social engineering against corporate users. The campaign combined spam pressure, Microsoft Teams communication, fake technical support, AutoHotkey scripts and a malicious Chromium extension called SNOWBELT.

The method was effective because it looked familiar. A user receives an unusual wave of messages or disruption. Then someone appears in a collaboration tool and offers to help. The attacker does not need to bypass every technical control at the start. The goal is to make the user follow instructions that open the door.

The malicious extension is an important part of the story. A browser is no longer just a window to the internet. In many companies, it is the workspace itself. Employees access email, CRM, cloud applications, internal portals, password reset pages and AI tools through it. A malicious extension can therefore observe, redirect, collect and manipulate a large part of the user’s working day.

This is a strong red-team scenario because it is not based on a magic exploit. It combines noise, urgency, trust and a tool that users already consider normal. If a company does not control extensions, does not monitor unusual browser behavior and does not train employees on fake internal support, the attack does not need to be technically complicated.

22 April

Lovable: a public project can mean more than a public application

Lovable published a detailed response to an April incident. A researcher discovered weaknesses that made it possible to access data from other users’ projects. The company said the issue affected the ability to view certain information related to public projects and that it updated its controls and internal processes after the report.

The wider point is more interesting than one platform. AI-assisted development tools are changing how quickly people create applications. They also change where sensitive information appears. Source code, prompts, generated application logic, database references and configuration details can end up in places the team does not treat as production.

In a real attack path, a public project is rarely the final target. It is reconnaissance. It tells an attacker what frameworks are used, how the application is structured, which databases are referenced, how authentication is designed and sometimes whether credentials were accidentally included in code.

For Haxoris, the practical message is clear. If a tool can generate applications, store project history, call services and remember context, it has to be reviewed as part of the software supply chain. It is not only a productivity tool. It is a place where the company’s architecture can leak in fragments.

19 April

Vercel and Context.ai: an access token as a silent entry badge

Vercel published a security bulletin about an April incident linked to Context.ai, a third-party Chrome extension. The entry point was not a direct compromise of Vercel’s core infrastructure. The issue started with a third-party integration that had access to a user’s Google Workspace environment.

Context.ai also published its own security update. The incident showed how powerful OAuth tokens can be when an application receives broad permissions. A token does not need to know a password. It can keep working silently until it expires or is revoked. If the scope is too broad, it can become an entry badge into a much larger environment.

This is the uncomfortable reality of modern SaaS. A company can have strong passwords, multi-factor authentication and good identity policies, but still expose sensitive data through an application that someone connected months ago. Productivity tools, browser extensions, AI assistants and analytics products often ask for access to email, calendars, documents, drives and user profiles. Users approve them because the workflow demands it.

In red-team work, OAuth consent is one of the most useful paths to evaluate. Which apps are connected? Who approved them? What scopes do they have? Are they reviewed? Can the security team revoke them quickly? Does anyone notice when a token starts accessing data at unusual times or from unusual places?

This incident is not only about Vercel. It is about every company where “allow” has become part of daily work.

17 April

Codex during an incident: when a user brings AI into a compromised system

Huntress described an unusual incident on a Linux endpoint. Multiple attackers were active on the system, installing cryptocurrency miners, collecting credentials and preparing further malicious activity. At the same time, the user was using OpenAI Codex on the same machine to help audit and respond to the suspicious behavior.

The Huntress agent was installed only in the middle of the compromise. The team therefore did not have full historical telemetry. The investigation was also complicated by the fact that commands generated by Codex sometimes looked similar to attacker commands. The user was trying to help, but created another layer of noise at the exact moment when analysts needed to separate legitimate actions from malicious activity.

This is a new category of incident. A user sees a problem, opens an AI assistant, lets it run diagnostics, edit files, suggest commands and “fix” the system. Meanwhile, the attacker may still be active. Without clear rules, the situation becomes chaotic and the investigation takes longer.

For companies, the conclusion is practical. Incident response should not be improvised by an end user with an AI assistant. If an employee suspects compromise, they must know what to do, whom to contact and what not to run. AI can help experts, but it should not replace a controlled incident response process.

In offensive security testing, this layer will become increasingly important. The future of defense will not involve only the security operations center, tools and analysts. It will also include users who try to quickly ask AI for help. If processes do not address that, a new weakness appears.

Microsoft Defender: when a protection tool becomes a path to higher privileges

Huntress also published research into the Nightmare-Eclipse intrusion and a privilege escalation technique named BlueHammer. The technique abused behavior around Microsoft Defender to gain local administrator rights.

Cases like this are uncomfortable because they involve a security product. Organizations naturally trust protective tools. They run with broad privileges, interact with sensitive parts of the system and are present across many endpoints. If a flaw or abuse path appears in this layer, the result can be very powerful.

For an attacker, local administrator rights on an endpoint are often a turning point. They allow dumping credentials, disabling controls, installing persistence, accessing sensitive files and preparing lateral movement. If the compromised machine belongs to an administrator, developer or user with privileged cloud access, the impact grows quickly.

The lesson is not “do not use Defender”. The lesson is that even protective layers must be monitored, updated and included in offensive validation. A tool that protects the company can also become part of the attack path if its behavior is misunderstood or misconfigured.

16 April

Nginx UI: web server administration as a path to production

SecurityWeek and other sources reported CVE-2026-33032 in Nginx UI, a web interface for managing Nginx servers. The issue was linked to a new Model Context Protocol integration and allowed an unauthenticated attacker to take control of the server. Thousands of internet-exposed instances were reportedly present.

This case is interesting because it connects two things companies often underestimate: management interfaces and new AI-related integrations. Nginx UI is not just a nice panel. It manages web server configuration, traffic routing, certificates, reverse proxies, redirects and sometimes access to internal applications.

If an attacker controls this point, they do not need to immediately read the database. They can change routing, insert malicious redirects, intercept traffic, prepare phishing on a legitimate domain or create more durable access.

From the Haxoris point of view, this is another reminder that the network edge is no longer a single firewall. It is a collection of management interfaces with more power than their owners often admit.

15 April

Model Context Protocol: when an AI tool gets too close to the system

Security researchers warned about weaknesses in how Model Context Protocol can be used. The problem was not just one specific application. It was the broader principle: tools connected to AI systems may, through unsafe configuration or command handling, gain the ability to execute commands on a system.

The Hacker News, citing OX Security, reported that the risk affected multiple projects and could lead to access to user data, internal databases, application keys and conversation histories. The important point is that this type of issue appears at the boundary between an assistant, a tool and the operating environment.

For companies, this is a warning against connecting AI blindly to everything. If a model or its tool can read files, call external services, run scripts or work with internal data, it is not a harmless assistant. It is a new execution channel.

In offensive security testing, the question is not only “which model do you use?” We want to know what it is allowed to do. Which files can it read? Which commands can it run? Which secrets can it see? What happens when a user puts something into a conversation that the model or tool interprets as an instruction?

NIST and an overloaded world of vulnerabilities

NIST announced changes to how it processes vulnerabilities in the National Vulnerability Database. The reason was the sharp growth in CVE records. In practice, defenders can no longer assume that every vulnerability will quickly receive complete enrichment and context.

For technical teams, this may sound like an administrative detail. For company leadership, it is an important signal. The number of vulnerabilities is growing faster than people’s ability to manually process them all. Without prioritization based on real impact, internet exposure, active exploitation and the value of the affected system, security turns into an endless task list.

From the attacker’s point of view, that is convenient. They only need to wait until the company cannot keep up. From the Haxoris point of view, this is why it makes sense to test attack paths, not only count findings. Ten critical vulnerabilities in a list may matter less than one quiet issue that leads directly to tokens and production.

14 April

Composer: a malicious project as a command on your developer machine

Two vulnerabilities were disclosed in PHP’s Composer tool, tracked as CVE-2026-40176 and CVE-2026-40261. The issue involved handling of Perforce repository configuration. An attacker controlling a malicious composer.json or source reference could cause command execution in the context of the user running Composer.

This is the kind of flaw that is easy to underestimate inside companies. A developer opens a third-party project, installs dependencies and assumes libraries will be downloaded. In reality, developer tools often behave like execution environments. They read configuration, call external systems, run scripts and use local credentials.

In offensive testing, the developer environment is a very attractive target. Not because developers are doing something wrong, but because their machines often hold access to repositories, test databases, cloud accounts, internal packages and deployment tools. If a malicious project runs in the wrong environment, it can become the first step into the company.

Microsoft Patch Tuesday: many fixes, little time

Microsoft’s April updates addressed 167 vulnerabilities, including two zero-day flaws. Eight vulnerabilities were rated critical, most of them allowing remote code execution.

This is not a section about the importance of patching. Everyone already knows that. The more important part is the reality inside companies. A security team receives dozens of fixes in one day. Some systems are critical, some are old, some belong to a vendor, some have exceptions, some cannot go down during business hours and some have no clear owner.

Attackers know this reality. They do not need a company to ignore every patch. They only need the company to postpone the one exposed to the internet or the one that enables privilege escalation after initial access. That is why patching should be organized around the attack path: what is externally reachable, what is actively exploited, what leads to higher privileges and what protects the highest-value systems.

13 April

Itron: when an attack on a supplier touches critical infrastructure

Itron, a major supplier of technology for energy, metering and urban infrastructure, confirmed an attack in which threat actors accessed parts of its internal IT environment. The company said it detected the incident on 13 April, activated its response plan, engaged external advisors and did not observe material disruption to operations or impact on customers.

The important part is who Itron is. The company supplies smart meters, sensors and data platforms to thousands of utilities and cities in more than a hundred countries. Even if the incident did not affect customers according to the company, it reminds us that the supply chain of critical infrastructure is not an abstract concept.

In offensive security testing, suppliers are part of the attack path. Not every attack has to begin directly at the operator. Sometimes it makes more sense to look for weakness in a tool, support channel, remote access method, update process or data platform that naturally holds trust across multiple customers.

For companies, the conclusion is simple: supplier assessment should not be a questionnaire once a year. It should include technical questions. What access does the supplier have? How is it logged? How is it revoked? What incident response plan do they have? How quickly do they notify customers? What happens if one of their internal accounts is compromised?

Adobe Acrobat: PDF as an old but still effective entry point

Adobe released an emergency fix for Acrobat and Acrobat Reader for CVE-2026-34621. The vulnerability allowed code execution after opening a malicious PDF file, and Adobe confirmed it was actively exploited.

This type of vulnerability is interesting because it does not feel modern. PDF is an old format that users open every day. Invoices, contracts, orders, documentation, legal materials, CVs, attachments from suppliers. That is exactly why it remains useful as an entry point.

From the attacker’s point of view, a malicious document is often cheaper than finding an exotic bug in the main application. It only needs the right story, the right sender, the right timing and a vulnerable client. If the user has access to internal systems, the document can become the first step in the attack path.

For companies, this means endpoint protection, document isolation, fast updates and limited user privileges are not boring hygiene. They are the layers that decide whether opening an attachment becomes an incident.

10 April

Marimo: a data notebook as a shell without login

Sysdig warned that the critical vulnerability CVE-2026-39987 in Marimo was exploited within ten hours of disclosure. Marimo is an open-source Python notebook for data science and analysis. The flaw was that the WebSocket endpoint for the terminal lacked sufficient authentication, allowing an unauthenticated attacker to obtain a full shell on the system.

This is a strong example of how the boundary between development, data analytics and production is changing. Notebooks are often started quickly, sometimes temporarily, sometimes in the cloud, sometimes with access to data, models, databases and tokens. That is exactly why attackers find them attractive.

If a notebook runs on a server with access to the internal environment, a seemingly small tool can become an entry point. The attacker obtains a command line, checks environment variables, configuration files, command history and data connections, and continues from there.

The practical point for companies is simple: temporary analytics and development tools must be in the asset inventory. If they are not recorded, nobody patches them, nobody monitors them and nobody knows what access they hold.

8 April

Ivanti EPMM: mobile management as a gateway into the network

CISA added CVE-2026-1340 in Ivanti Endpoint Manager Mobile to its catalog of known exploited vulnerabilities. The issue allowed code injection in a product used to manage mobile devices.

Device management systems have a special position in companies. They know about devices, policies, profiles, certificates, applications and often what is allowed to connect to the corporate environment. If an attacker reaches that layer, they do not get only one server. They get a control point over a fleet of devices.

From an offensive testing perspective, this is a very sensitive target. Mobile device management, endpoint management and remote access often sit on the boundary between the internet and the internal environment. They are designed for administration, so they naturally carry broad privileges.

That is why these systems should not be patched “when there is time”. If they are exposed externally and the vulnerability appears in a known-exploited catalog, this is not routine maintenance. It is a decision about whether you leave a control panel open to attackers.

7 April

Flowise: an AI agent builder as a code execution path

VulnCheck and other sources reported active exploitation of CVE-2025-59528 in Flowise. Flowise is an open-source platform for building AI applications and agents. The flaw had the highest severity rating and allowed code execution through unsafe handling of configuration in the CustomMCP node.

The important point is that Flowise is not just a text tool. It runs as a service, connects to models, storage, internal systems, APIs and automated workflows. If an attacker gains code execution on such a server, they may access files, secrets, integration keys and data sources.

This is the broader problem with new AI tools. Companies often deploy them as experiments. Attackers treat them as infrastructure. If they have access to internal data and systems, they must be protected like production systems, not like toys for the innovation team.

In testing, we would ask very directly: where does Flowise run, who logs in, what is connected, which keys are stored, whether the interface is internet-exposed and whether configuration can lead to command execution.

5 April

Fake Strapi packages in npm: when the plugin is not a plugin

Security researchers discovered 36 malicious packages in the npm registry pretending to be Strapi plugins. They used names beginning with strapi-plugin- to appear trustworthy, but in reality contained malicious scripts for data theft, Redis and PostgreSQL abuse, reverse shells and persistence.

This case is interesting because it was not just a simple token stealer. According to the analysis, the attackers attempted several paths: Redis abuse, reconnaissance, credential theft and maintaining access.

For development teams, this is another reminder that a package name is not proof of trust. In ecosystems with thousands of packages, attackers often do not try to break through defenses. They try to look enough like the legitimate thing a developer expects.

From the Haxoris point of view, this is a process question. Does the company have rules for new dependencies? Can it see what runs during installation? Does it restrict rights in the build environment? Does it know which packages are used in production? If not, the supply chain is not being tested. It is simply being trusted.

2 April

Progress ShareFile: a file exchange gateway as an entry point into the company

watchTowr Labs published research on Progress ShareFile Storage Zone Controller. Two vulnerabilities, CVE-2026-2699 and CVE-2026-2701, could be chained to achieve remote code execution before authentication. The affected component is a customer-managed gateway through which organizations store and provide access to files in their own infrastructure.

The danger was that the attacker did not need credentials. Network access to the affected Storage Zone Controller was enough. After bypassing authentication, the attacker could execute arbitrary code on the underlying system. According to watchTowr, StorageCenter versions 5.x through 5.12.3 were affected, with 5.12.4 being the fixed version.

ShareFile is a good example of a system companies often see as a secure file exchange channel, not as a critical network boundary. But these portals sit exactly between the external world and internal data. They handle authentication, document access, storage configuration, network shares, cloud storage and communication with clients.

For an attacker, this is an attractive target. It combines external exposure with high-value data. If such a gateway is compromised, the attacker does not need to search the entire network for sensitive information. Much of it naturally flows through this system.

What April leaves us with at Haxoris

If we turned April’s cases into one offensive exercise, it would not begin in a cinematic way. There would be no dramatic breach of the main gate. It would start with something ordinary: a new package in a project, a testing tool exposed to the internet, a stressed user, a permission granted to an app that promised to save time, or an older portal nobody considers critical anymore.

That is how interesting incidents are built today. Not from one magical flaw, but from a combination of small things that look harmless on their own. One gives the attacker entry. Another opens more privileges. A third shows where the keys are stored. A fourth allows movement without making much noise.

For company leadership, one thing matters most: security cannot be judged only by whether a scan, audit or training session happened. All of that has value, but it is not enough. A real attack does not ask whether a system is formally classified as critical. It asks whether it is reachable, whether it has privileges, whether it stores tokens, whether anyone monitors it and whether anyone notices when it starts behaving differently.

April also showed that new technologies bring not only new opportunities, but new blind spots. AI tools, build automation, developer platforms and chat applications have become a natural part of business life. Attackers do not see them as add-ons. They see them as doors.

From the Haxoris point of view, the most important thing is to test the company as a living environment, not as a list of IP addresses. Where would we get the first foothold? Where would we move after compromising one account? Which tool has too many privileges? Where are the keys stored? Which process would a person under pressure bypass? What happens if the attacker does not target the most visible system, but the most useful one?

That is why offensive security testing is becoming more valuable. Not because it finds the prettiest CVE. Because it shows whether a routine incident can become a real business problem. April gave more than enough examples.

Frequently asked questions

Who is this April Throwback for?

It is written for security teams, developers, IT leaders and company management working on red teaming, penetration testing, NIS2, cloud security, DevSecOps or AI security.

Why does the article focus on attack paths?

A list of vulnerabilities is not enough. An attack path shows how an adversary could connect initial access, tokens, cloud, CI/CD, identity, applications and users into a real business incident.

How can Haxoris help?

Haxoris helps companies validate their attack surface through red teaming, penetration testing, cloud and application security testing, CI/CD reviews, security exercises and practical risk-reduction recommendations.

Sources and recommended reading

Related articles

Do not wait for attackers - uncover your weakest point with a penetration test now!

Book now