#remotecodeexecution

Read Time:3 Minute, 21 Second

Attackers are actively targeting a critical vulnerability in Bricksforge, a WordPress extension for the Bricks site builder, to upload files that the server later executes as PHP. The issue, tracked as CVE-2026-85097, has a CVSS score of 10.0 and can be exploited without an authenticated account. That combination makes exposed sites attractive targets for automated scanning and rapid compromise.

Patchstack observed the first exploitation attempts on October 7, 2026. The vulnerable range includes Bricksforge through version 3.1.8.9, while version 3.1.8.10 contains the cited fix. The vendor has also pointed users to a Pro Forms upload security correction in version 4.0.1, released October 8. Administrators should move to the newest supported release rather than assuming that forms without visible upload fields are safe.

How an image upload becomes executable codeThe attack exploits a mismatch between two stages of Bricksforge’s form workflow. During the initial upload, the plugin checks the file’s MIME type, which can make a submitted object appear to be an acceptable GIF or PNG. Later, when the form is completed, Bricksforge processes temporary upload metadata supplied by the visitor but does not adequately validate the destination URL.

An attacker can therefore provide a file that satisfies the image check while also containing PHP code. A crafted form submission associates its temporary server path with a destination whose name ends in an executable PHP extension. When the plugin copies the content to that location, the attacker only needs to request the new file to make the web server run the embedded code.

The publicly reachable bricksforge_regenerate_nonce AJAX action can also provide the request token needed by the attack flow. In practice, this means the protection normally associated with a nonce does not turn the vulnerable form endpoint into an authenticated-only surface.

Exploitation is broad and automatedNearly all captured attempts targeted /wp-json/bricksforge/v1/form_submit, although activity also reached the corresponding WordPress AJAX action. Most requests used a temporary path ending in .gif or .png and paired it with a PHP destination. Attackers tested extensions such as .php5, .php8 and .phtml, plus mixed capitalization and encoded filenames designed to bypass simplistic filters.

Patchstack recorded activity from 63 source IP addresses. One burst involved 44 addresses sending identical requests within seconds, while another group tried numerous extension and encoding combinations. The distribution does not identify a particular threat actor, but it strongly suggests repeatable tooling rather than isolated manual research.

What a successful intrusion enablesRemote PHP execution gives an intruder a foothold inside the WordPress environment. Depending on hosting permissions and configuration, the attacker may be able to install a web shell, read database credentials, alter pages, create administrator accounts, steal customer information or use the site to redirect visitors. A planted script can also preserve access after the plugin itself has been updated.

That persistence risk is why patching alone is insufficient for systems that were exposed while exploitation was underway. A clean version closes the known entry point, but it does not automatically remove files or accounts created earlier.

Immediate response steps for site ownersUpgrade Bricksforge to the latest vendor-supported release, with 3.1.8.10 identified as the minimum fixed version for the reported flaw.

Search access logs for suspicious requests to the REST form submission route, the AJAX form action and the nonce-regeneration endpoint.

Inspect /wp-content/uploads/bricksforge/tmp/ and other upload folders for PHP, PHTML or unusually named image files.

Review recently created WordPress administrators, modified themes and plugins, scheduled tasks, database changes and outbound connections.

If compromise is suspected, rotate WordPress salts, administrator passwords, database credentials and hosting control-panel secrets after containment.

Web application firewall rules may reduce immediate exposure when an update cannot be deployed at once, but they should be treated as a temporary safeguard. Because active exploitation has already been documented, vulnerable or recently patched sites deserve a focused incident review rather than a routine update-and-close response.

Read Time:3 Minute, 24 Second

GitLab has released security updates for a maximum-severity vulnerability that could let a remote attacker execute code on a self-managed server without first signing in. CVE-2026-97229 carries a CVSS score of 10.0 and affects both GitLab Community Edition and Enterprise Edition, placing the issue at the top of the patch queue for organizations that run their own development infrastructure.

The company published corrected versions on October 12, 2026. GitLab.com already uses patched software, and GitLab Dedicated customers do not need to perform the upgrade themselves. The urgent action applies to self-managed instances in the affected branches.

A CI/CD expression reaches the serverThe vulnerability is an integer overflow in GitLab’s regular-expression compiler for continuous integration and delivery workflows. Regular expressions are patterns used to identify or transform text, and they are common in pipeline rules. According to the advisory, insufficient validation could allow a specially constructed expression in CI/CD configuration to trigger arbitrary code execution.

The public description says exploitation is possible under certain conditions but does not disclose a complete recipe. Even with those details withheld, the severity vector is stark: the attack is reachable over a network, has low complexity, needs neither privileges nor user interaction, and can have a high impact on confidentiality, integrity and availability.

This is not a browser-only script injection that disappears when a tab closes. The potential execution occurs on the GitLab server, where repositories, build metadata, secrets and automation converge. GitLab credited researcher joaxcar, who reported the problem through the company’s HackerOne program.

Why a GitLab takeover can spreadA compromised source-code platform offers more than access to individual repositories. Attackers may seek CI/CD variables, deploy keys, package registries, runner credentials and service tokens. If those secrets grant access to cloud accounts or production environments, a single server flaw can become the first stage of a broader software supply-chain incident.

An intruder with server-level execution could also modify code, tamper with build artifacts, interrupt pipelines or erase evidence. Even organizations that mirror repositories elsewhere would need to examine whether trusted releases or container images were produced during the period of suspected access.

Affected versions and fixed releasesGitLab identifies three affected release lines. Administrators should update according to the branch they currently operate:

GitLab 19.2 installations earlier than 19.2.8 should move to 19.2.8 or a later supported release.

GitLab 19.3 installations earlier than 19.3.4 should move to 19.3.4 or later.

GitLab 19.4 installations earlier than 19.4.2 should move to 19.4.2 or later.

Version 19.3.4 has a known issue affecting merge-request pages when the Ona integration is enabled, with a correction expected in 19.3.5. Teams using that integration should plan around the compatibility problem, but it should not become a reason to leave the critical code-execution vulnerability open.

The same security release addresses additional weaknesses, including authorization problems, cross-site scripting and an issue associated with the GitLab Duo Agent Platform. Reviewing the complete release notice is important because an upgrade can close several independent attack paths at once.

Defensive priorities after upgradingAdministrators should first inventory every internet-facing and internal self-managed instance, including forgotten test servers and disaster-recovery nodes. After upgrading, teams should review application, audit, runner and reverse-proxy logs for unusual pipeline submissions, malformed expressions, unexpected project creation, new access tokens and unexplained child processes.

Secrets stored in CI/CD variables deserve special attention if exploitation is suspected. Incident responders should determine which credentials were accessible, revoke them in the systems where they are honored and then replace them in GitLab. Merely changing the value in the project does not invalidate a token at its destination.

GitLab has not said that CVE-2026-97229 is being exploited in real-world attacks. However, the absence of confirmed exploitation is not a safe maintenance window for a network-accessible, unauthenticated CVSS 10 flaw. Fast patching, targeted log review and credential hygiene are the proportionate response.

Read Time:3 Minute, 36 Second

Google has corrected a critical vulnerability chain in its shared DevSite platform that could have allowed an unauthenticated attacker to execute code on multiple developer-focused web properties. The weakness combined exposed OAuth material, reuse of a secret key and unsafe Python deserialization, turning a seemingly ordinary session cookie into a route toward server compromise.

The affected platform supported sites including developers.google.com, firebase.google.com, developer.android.com, source.android.com and docs.partner.android.com. Researcher Simon Koeck reported the issue in August, and Google reportedly completed its fix on October 7, 2026. The company’s Vulnerability Reward Program paid a $90,000 bounty.

A readable cookie exposed the key protecting itThe chain began at a DevSite OAuth endpoint that issued a Flask session cookie. Flask’s default client-side sessions are signed to prevent undetected modification, but their contents are not encrypted. A user can inspect the stored data even though changing it should invalidate the signature.

After decompressing and decoding the cookie, the researcher found that it contained a serialized OAuth flow object, including a Google OAuth client ID and client secret. The crucial discovery was that the OAuth client secret was also being used as the Flask application’s session-signing key.

This amounted to putting the verification secret inside the object it was supposed to protect. Anyone who obtained a cookie could recover that key, alter session values and create a new signature that the server would accept as authentic. Because the OAuth authorization endpoint was reachable without a Google account, acquiring the starting cookie did not require an authenticated user.

Unsafe deserialization completed the RCE chainForging a trusted session was serious, but another design choice converted it into remote code execution. During the OAuth callback, the application reportedly Base64-decoded an OAuth flow object stored in the session and passed the result to Python’s pickle.loads().

Python’s pickle format can reconstruct complex objects, and that process may invoke functions. It is therefore unsafe for any data an attacker can influence. With the signing key in hand, an attacker could build a session containing a malicious pickle payload, sign it correctly and send it through the callback. The application would accept the cookie and deserialize the attacker-controlled object.

Koeck avoided running operating-system commands against Google’s infrastructure. Instead, the proof of concept used a harmless delay: requests paused for the precise number of seconds encoded in the payload. That behavior demonstrated that the selected Python function had executed while minimizing impact.

Shared infrastructure magnified the riskThe finding affected a common DevSite service rather than a single isolated documentation page. Shared components improve consistency and maintenance, but a security defect can inherit the combined reach of every property using them. In this case, the potential target set included prominent Android, Firebase and Google developer resources.

The vulnerability also illustrates why individually familiar mistakes can become critical when chained. A client-readable cookie is normal for signed Flask sessions. An OAuth client secret must remain confidential, while key reuse weakens separation between trust domains. Finally, pickle assumes its input is trusted. When the secret leaked and enabled session forgery, that final assumption collapsed.

Google’s fixes and lessons for developersThe remediation reportedly included rotating the exposed OAuth client secrets, invalidating sessions signed with them, separating Flask signing keys from OAuth credentials and moving OAuth flow objects into server-side storage. A browser cookie can then contain only an opaque reference rather than the sensitive object itself.

Engineering teams can use the case as a practical review checklist:

Never place credentials, signing keys or recoverable secret material in client-visible state, even when the container is signed.

Use separate secrets for OAuth, session integrity and other security boundaries so a leak in one system does not unlock another.

Avoid pickle and similar executable serialization formats for data influenced by browsers, users or partner integrations.

Prefer data-only encodings such as JSON with strict schema and type validation.

After key exposure, rotate the secret and invalidate artifacts that were signed or encrypted with the old value.

The incident shows that a valid cryptographic signature proves little if the signing key is disclosed to the same client. Trust also depends on keeping secrets out of observable state and ensuring that data processing cannot unexpectedly become code execution.

Read Time:3 Minute, 29 Second

A public proof-of-concept has raised the urgency around a critical AnyDesk vulnerability on Linux that can permit remote command execution before authentication or user approval. The flaw, dubbed AnyPwn, affects AnyDesk Linux 8.0.2 and was corrected in version 8.0.3, but the release of working exploit code gives attackers a practical starting point for probing systems that remain unpatched.

The vulnerability was reported by security researcher Rick de Jager of V12. AnyDesk acknowledged the report and shipped its fix in June 2026. Public code released on October 8 now demonstrates exploitation against the vulnerable Linux build in service mode on x86-64 hardware.

A length calculation becomes memory corruptionAnyPwn resides in the session protocol used when a remote client connects to AnyDesk. In the affected mode-5 stream-packet handler, the application accepts an attacker-controlled payload length before validating it safely. It then adds a 16-byte object header using 32-bit arithmetic.

A specially chosen length can make that addition wrap around to a small value. The program consequently allocates a much smaller memory region than the object supposedly requires, then copies attacker-controlled data as though the buffer were large. The resulting out-of-bounds write can corrupt nearby memory and redirect execution.

The key operational concern is privilege. AnyDesk’s Linux service normally runs as root, so code launched through the vulnerable process inherits the operating system’s highest authority. A successful attacker could alter files, create accounts, interfere with security tools, collect credentials or establish persistent access before anyone accepts a remote desktop request.

Direct exposure presents the confirmed routeThe published exploit connects directly to TCP port 7070. It depends on offsets and a memory layout associated with the specific vulnerable build, so every attempt will not necessarily produce code execution; an unsuitable layout may instead crash the service. That limitation should not be confused with safety, because attackers can adapt public research and retry against reachable hosts.

AnyDesk initially characterized the issue as affecting direct Linux connections, not its Windows or macOS clients. Researchers said they could also reach the vulnerable code path through relay connections in testing, but did not demonstrate the complete root-execution chain over that route. Internet or untrusted-network exposure of port 7070 therefore represents the clearest confirmed danger, while defenders should not assume relay use eliminates all risk.

Patch first, then investigate exposureOrganizations should inventory Linux installations immediately and upgrade AnyDesk 8.0.2 and any older affected deployment to version 8.0.3 or later. Version checks should include servers, administrator workstations, support jump boxes and forgotten systems where remote-management software was installed temporarily.

If an update cannot be completed at once, firewall rules, VPN policy and cloud security groups should prevent untrusted clients from reaching TCP/7070. Access should be limited to explicitly required management networks rather than broad address ranges.

Search perimeter records for systems that exposed port 7070.

Review AnyDesk logs for unfamiliar connection attempts and service crashes.

Investigate unexpected root-owned processes, accounts and persistence entries.

Examine outbound traffic from affected machines for new or rare destinations.

Rotate privileged credentials if compromise cannot be confidently excluded.

Remote-support software deserves server-grade controlsRemote-access tools occupy an unusually sensitive position: they are trusted to cross normal administrative boundaries and are often present on high-value machines. That makes a pre-authentication flaw especially serious, but it also makes routine hardening valuable. Teams should centrally manage installations, remove unused agents, restrict listening interfaces and place remote administration behind layered network controls.

Application allowlisting and endpoint monitoring can help detect follow-on activity, while an accurate software inventory shortens the time between an advisory and remediation. Organizations should also treat externally reachable remote-management services as part of their attack surface and test them continuously.

The public exploit does not mean that every AnyDesk platform is equally vulnerable, nor does it establish that mass exploitation is underway. It does mean that the technical barrier has fallen for the precise Linux configuration demonstrated. Patching and exposure review are now time-sensitive defensive work, not tasks to leave for the next routine maintenance window.

Read Time:3 Minute, 13 Second

Citrix is urging administrators to update NetScaler ADC and NetScaler Gateway appliances after disclosing a critical memory-overflow vulnerability that can lead to remote code execution or denial of service. The issue, tracked as CVE-2026-107406, received a CVSS 4.0 score of 9.5 and is documented in Citrix bulletin CTX697191.

The vulnerability is especially important for organizations that place NetScaler systems at the edge of their networks for application delivery and authentication. An exposed gateway is not simply another server: it may sit directly in the path used by employees and partners to reach sensitive services. Citrix said it was not aware of unmitigated exploitation when it published the advisory, but defenders should not treat that statement as a reason to delay remediation.

Exposure Depends on the SAML Role and Installed BuildCVE-2026-107406 is categorized as CWE-119, a failure to properly restrict memory-buffer operations. Citrix says a successful network attack could execute code or interrupt service without requiring an authenticated account or user interaction. The attack complexity is rated high, and the vendor has not released exploit details.

Determining exposure requires more than checking the major NetScaler version. On branches 14.1 and 13.1, several recent build ranges are vulnerable only when the appliance is configured as a SAML identity provider. Older supported builds can be exposed when operating as either a SAML identity provider or a SAML service provider. FIPS and NDcPP releases have their own affected thresholds.

Administrators can inspect configuration entries for add authentication samlIdPProfile, which indicates an identity-provider role, and add authentication samlAction, which identifies a service-provider configuration. Those entries must then be evaluated alongside the exact installed build. An inventory that records only “NetScaler 14.1” is not detailed enough for this decision.

Fixed Releases Are Available Across Supported BranchesCitrix recommends moving NetScaler ADC and Gateway systems to version 14.1-73.46 or later on the 14.1 branch, or 13.1-64.29 or later on the 13.1 branch. Customers using 14.1-FIPS should install 14.1-73.46 FIPS or newer. The fixed level for 13.1-FIPS and NDcPP is 13.1-37.283 or later.

Secure Private Access Hybrid environments that rely on affected customer-managed NetScaler instances also need attention. Citrix-managed cloud services and Citrix-managed Adaptive Authentication are maintained by the vendor and are outside the customer-managed appliance scope described in the bulletin.

Recent NetScaler security incidents make version discipline particularly important. Applying an earlier emergency patch does not necessarily protect an appliance from this newly disclosed flaw. Teams should use CTX697191 as the authoritative reference, confirm their branch and SAML role, and select the fixed build specified for that combination.

What Security Teams Should Do NowBuild an inventory of internet-facing and internally deployed NetScaler ADC and Gateway instances.

Record the complete build number and whether each system acts as a SAML identity provider, service provider, or both.

Upgrade to the applicable fixed release and confirm that the new version remains installed after reboot or failover.

Review administrative changes, crashes, unusual child processes, and unexpected authentication behavior around exposed appliances.

Restrict management interfaces and preserve logs before remediation if suspicious activity is found.

Because the flaw can affect a device at a high-trust network boundary, patching should be paired with investigation rather than treated as a purely operational upgrade. If telemetry suggests compromise, responders should consider credentials and sessions passing through the gateway potentially exposed, isolate the device where feasible, and follow Citrix’s incident guidance. After updating, teams should test authentication flows and high-availability pairs so that emergency remediation does not leave a silent service or failover gap. The absence of a public exploit at disclosure lowers immediate evidence of mass abuse, but it does not reduce the consequence of a successful attack.

Read Time:3 Minute, 27 Second

Apache Struts users are being urged to update after maintainers detailed four vulnerabilities affecting different parts of the Java web framework. Depending on configuration and application behavior, the flaws can enable remote code execution, exhaust memory or processing resources, or reveal one user’s formatted data to another.

The recommended destination is Struts 7.4.0 or later. Organizations remaining on the supported 6.x line should install version 6.12.0 or later. The advisories do not establish that any of the issues are being exploited in the wild, but internet-facing Struts applications deserve prompt review because one flaw can turn a crafted request into code execution.

Legacy mapper creates an OGNL injection pathCVE-2026-104711 affects the legacy RESTful action mapper. A malicious request can place an Object-Graph Navigation Language expression into values derived from the URL, potentially allowing code to run on the server. The vulnerable ranges are Struts 2.0.0 through 2.3.37, 2.5.0 through 2.5.33, and 6.0.0 through 6.11.0.

Struts 7.0.0 through 7.3.0 is exposed only when its OGNL allowlist has been disabled. The default mapper, the restful2 mapper and the Struts REST plugin are not affected by this particular defect. That distinction is important: teams should confirm the mapper actually configured in production instead of assuming every Struts deployment has identical risk.

Two denial-of-service conditions target different resourcesCVE-2026-104712 lets a small request provoke a disproportionately large response when parameters populate java.math.BigDecimal properties that are rendered with the Struts tag library. Repeated low-volume requests could consume CPU and outbound bandwidth. Applications using other numeric types or returning content through the JSON or REST plugins are outside the described exposure.

The affected versions are 2.5.14 through 2.5.33, 6.0.0 through 6.11.0, and 7.0.0 through 7.3.0. If an immediate upgrade is impossible, a custom BigDecimal converter can restrict scale before values are rendered, but that measure should be treated as temporary.

CVE-2026-104713 involves the optional REST plugin and carries the highest rating of the four, classified as Important. The vulnerable code reads request bodies into memory without enforcing a size ceiling. One oversized XML or JSON submission can therefore consume the Java heap and make the service unavailable. Fixed versions impose a default maximum of 2,097,152 characters.

This issue reaches back to Struts 2.1.8 and affects the relevant branches through 2.3.37, 2.5.33, 6.11.0 and 7.3.0. Reverse proxies or servlet containers can enforce request-body limits for organizations that cannot patch immediately, though defense at the edge should not replace the framework fix.

Shared formatter can mix data between usersCVE-2026-104714 concerns shared localized message formatters processing date or time arguments. Concurrent requests can interfere with one another, causing a value belonging to one request to appear in another response or producing rendering errors. Unlike the other issues, ordinary traffic may trigger the race without hostile input.

The defect affects listed Struts branches through 6.11.0 and 7.3.0. Formatting dates before inserting them into localized messages can reduce exposure until upgrades are complete.

Practical response for Struts administratorsSecurity teams should first inventory externally reachable Struts applications and record their exact versions and plugins. They should then inspect mapper settings, confirm whether OGNL protections were weakened, locate endpoints accepting REST bodies, identify BigDecimal properties rendered by tags and review localized message templates.

Upgrade to Struts 7.4.0 or 6.12.0 as the primary remediation.

Keep the OGNL allowlist enabled and retire the legacy RESTful action mapper.

Apply body-size limits at multiple layers and monitor heap pressure.

Review logs for unusual URLs, oversized bodies and repeated requests producing large responses.

Because the flaws depend on separate optional components and coding patterns, patching should be paired with configuration validation. A clean version number reduces the immediate risk, while a component-level inventory helps teams understand which attack paths were actually reachable before the update.

Read Time:3 Minute, 24 Second

A specially prepared HEIC image can do far more than fail to render on a WordPress site. Security researchers have demonstrated a chain that takes an ordinary Media Library upload, passes it through the site’s native image-processing stack, and ultimately executes code inside the PHP-FPM process. The work shows how a seemingly narrow bug in an image decoder can become a practical server compromise when it is combined with information disclosure and predictable application behavior.

The chain is not being described as a mass exploitation campaign, and it does not provide anonymous visitors with a universal route into every WordPress installation. In the tested scenario, the attacker first needs a logged-in account with the upload_files capability, normally an Author-level role or above. Even with that limitation, the result matters because compromised contributor accounts are common and image uploads are often treated as lower risk than executable files.

How the image reaches vulnerable native codeWordPress commonly relies on ImageMagick to create thumbnails and other derivatives after an image is uploaded. ImageMagick, in turn, can call libheif to decode HEIC, HEIF and AVIF content. The primary weakness, tracked as GHSA-x8r2-mggj-j6wr, sits in libheif’s uncompressed image decoder. A malicious file can describe color channels with inconsistent byte widths, causing the decoder to reserve too little memory before writing attacker-controlled data beyond the intended buffer.

That memory corruption can damage a nearby C++ object reference. During cleanup, the altered reference can redirect a virtual function call toward an attacker-chosen path. In plain terms, the decoder is manipulated into following hostile instructions while it believes it is finishing routine image processing. Successful code runs with the permissions of the PHP-FPM service account, identified as www-data in the researchers’ laboratory.

Memory disclosure makes the chain reliableModern Linux protections randomize where libraries are loaded, so a memory-corruption bug alone is not necessarily dependable. The researchers overcame that obstacle by uploading separate disclosure images and examining pixels in JPEG derivatives produced by WordPress. Those output images leaked enough process memory to identify the running library layout and prepare a final trigger for the specific stack.

Fortbridge validated the method on two tightly defined environments: an Ubuntu 26.04 system running WordPress 7.1.1 and a Debian 13 system running WordPress 7.0, each with particular PHP-FPM, ImageMagick and libheif builds. Code execution succeeded in six of eight fresh Ubuntu parent processes and 22 of 24 Debian parent processes. Those figures demonstrate repeatability under controlled conditions, but package or build differences can still disrupt the chain.

What WordPress administrators should doThe direct fix is to update libheif. Versions 1.18.0 through 1.23.2 are affected by the overflow, with the correction available in 1.23.3. A related disclosure weakness is fixed in 1.23.2. Administrators should install their distribution’s security packages and confirm which library the active ImageMagick installation actually loads; updating an unused copy does not protect the production image worker.

Block HEIC, HEIF and AVIF uploads when the formats are not operationally required.

Process untrusted media in an isolated, low-privilege service with restricted outbound access.

Keep application credentials and other secrets outside the image-processing environment.

Prevent script execution in upload directories and minimize writable web paths.

Review who holds upload permissions and remove access that is no longer necessary.

Detection should focus on the processing layerDefenders should investigate repeated PHP-FPM worker exits or HTTP 503 responses that occur immediately after HEIC uploads. Files containing unusual unci, iden, crop, overlay or grid relationships deserve added scrutiny. A worker crash is not proof of code execution, but a cluster of failures around image conversion can reveal attempted exploitation.

Restricting upload directories reduces consequences but does not repair the native memory flaw. The broader lesson is that an uploaded image remains untrusted code-like input once a complex decoder begins parsing it. WordPress security reviews therefore need to include the operating system libraries behind media conversion, not just plugins, themes and the core application.

Read Time:3 Minute, 23 Second

GitLab has issued urgent fixes for a near-maximum-severity weakness in its self-hosted AI Gateway, warning that a user with limited but valid access could cross a template-processing boundary and run commands on the underlying service. The vulnerability, tracked as CVE-2026-90970, has a CVSS score of 9.9 and affects infrastructure supporting GitLab Duo AI features.

The issue is especially important for organizations that operate the gateway inside their own environment. Although exploitation requires an authenticated account with access to the Duo Agent Platform, the attack itself is network-accessible, needs no victim interaction and is considered low complexity. A successful compromise could affect the confidentiality, integrity and availability of the gateway and the systems or model backends it can reach.

How the sandbox escape worksThe flaw lies in the handling of custom flow prompt templates. Those templates are supposed to be processed inside a restricted sandbox so that user-controlled instructions cannot become operating-system commands. GitLab says a specially constructed flow configuration can escape that boundary, allowing arbitrary commands to execute on the AI Gateway.

This distinction matters. The risk is not merely that an attacker might manipulate an AI response or influence a model prompt. The vulnerable processing path can reach the service host itself. From there, the practical impact would depend on the gateway’s privileges, accessible secrets, network routes and connections to model services or other internal resources.

GitLab has not disclosed a working exploit, named the underlying template engine or reported attacks in the wild. The company credited researcher invisiblemeerkat with responsibly reporting the problem. Those details lower the immediate evidence of active abuse, but they do not reduce the urgency of a flaw that can convert a relatively constrained application role into command execution.

Affected versions and available fixesAffected AI Gateway versions begin with 18.1.6 and extend through releases earlier than 19.2.4. The 19.3 branch is vulnerable before 19.3.2, while the 19.4 branch is affected before 19.4.1. GitLab released AI Gateway 19.2.4, 19.3.2 and 19.4.1 to close the issue.

Administrators should check the deployed gateway component rather than assume the main GitLab instance version tells the full story. Customers using GitLab.com, GitLab Dedicated, or self-managed GitLab connected to a GitLab-hosted AI Gateway are already protected because GitLab updated its hosted infrastructure. The required action falls on customers running their own affected gateway.

Why self-hosted AI infrastructure needs attentionSelf-hosting gives enterprises greater control over AI requests and model backends, but it also places patching, image management and network isolation in the customer’s hands. AI orchestration services frequently sit between developer identities, source-code context, internal tools and external models. That position can make a compromised gateway a valuable pivot point even when the initial attacker account is not highly privileged.

Security teams should treat access to Duo Agent Platform features as meaningful application privilege. Review who holds that access, remove stale accounts and inspect authentication and gateway logs for unusual flow creation, template errors or command-like content. Any unexplained child processes or outbound connections from the gateway should receive prompt investigation.

Recommended responseUpgrade immediately to AI Gateway 19.2.4, 19.3.2, 19.4.1 or a later supported release.

For container deployments, verify the new image digest instead of relying only on a mutable tag.

For Kubernetes or Helm installations, ensure image caching and pull policies do not leave old code running.

Restrict unnecessary outbound traffic while preserving documented gateway dependencies.

Review Duo Agent Platform permissions and investigate suspicious template activity.

After upgrading, operators should run health checks and confirm that every replica uses the patched image. Network controls and least privilege can reduce exposure, but neither substitutes for replacing the vulnerable component. Given the severity and the gateway’s position in AI-enabled development workflows, patch validation should be handled as part of the incident-response process rather than routine maintenance.

Source: Cyber Security News, reporting on GitLab’s security release.

Read Time:3 Minute, 42 Second

cPanel has disclosed a set of security flaws in its cPanel & WHM hosting control panel, and the most severe of them is about as bad as it gets for a hosting environment: a path to arbitrary command execution as root. Published on September 29, 2026, the advisory affects every supported cPanel & WHM release prior to the vendor’s patched versions, meaning the exposure window spans a huge number of shared hosting and managed server deployments worldwide.

A Direct Line to Full Server CompromiseThe headline issue, tracked as CVE-2026-93698, stems from insufficient input validation in the Multilang adminbin component. cPanel’s advisory describes it plainly: the weakness allows arbitrary command execution, and that execution happens with root privileges. On a hosting server, root access doesn’t just mean one compromised account — it means every hosting account, website, database, and service running on that machine becomes reachable to the attacker in one shot.

That makes this a materially different risk profile than a typical web application bug. An attacker who successfully exploits the Multilang adminbin flaw could read or modify data across every customer hosted on the box, drop persistent malware, create new privileged accounts, harvest credentials, disable security tooling, and rewrite server configuration — all without needing to compromise each hosted site individually. For hosting providers and managed-service companies running shared infrastructure, a single unpatched server can translate into a mass-compromise event affecting dozens or hundreds of downstream customers.

Two Additional Stored XSS Flaws in WHMThe advisory also covers a pair of related cross-site scripting vulnerabilities that, while less severe than the command-execution bug, still carry meaningful risk in a multi-tenant hosting context. CVE-2026-93029 affects the WHM Manage SSL Hosts interface: a lower-privileged account holder could plant malicious script content that executes later when a WHM administrator views the affected page. Because that script runs inside the administrator’s own authenticated browser session, it can potentially carry out actions with the administrator’s own permissions — modifying server settings, managing hosting accounts, or altering SSL configuration.

CVE-2026-93697 follows the same pattern in a different location, the WHM Mass Modify Accounts interface. As with the SSL Hosts bug, successful exploitation requires an attacker to store malicious content that an administrator subsequently opens, at which point the injected code runs with the administrator’s session privileges. Both stored XSS issues effectively let a lower-tier account escalate its influence by hijacking an administrator’s browser rather than attacking the server directly — a reminder that privilege boundaries inside shared hosting panels can be more porous than they look.

Patch Availability and TimingcPanel has shipped fixes across its supported release lines. The patched versions are 11.110.0.148, 11.134.0.61, 11.136.0.45, 11.138.0.11, and WP2 11.138.1.13 — the same set of fixed releases applies to all three CVEs covered in the advisory (CVE-2026-93029, CVE-2026-93697, and CVE-2026-93698). At the time of disclosure, no public proof-of-concept exploit code had surfaced in available vulnerability-tracking sources. That’s a modest point in defenders’ favor, but detailed technical advisories tend to accelerate independent exploit development, particularly for internet-facing WHM interfaces that administrators haven’t gotten around to updating.

Recommended ResponseGiven the severity of the root-level command execution flaw in particular, hosting providers and server administrators should treat this as an urgent, non-negotiable patching priority rather than routine maintenance. Beyond simply applying the update, a thorough response should include:

Upgrading cPanel & WHM to the latest patched release for your product line without delay.

Reviewing WHM administrator activity logs, authentication records, and any newly created privileged user accounts for signs of prior compromise.

Auditing cron jobs and server or hosting-account configuration changes for anything unexpected.

Restricting WHM access using firewall rules, VPN-only access, IP allowlisting, and multi-factor authentication, rather than leaving the administrative interface broadly reachable.

Reviewing the privileges granted to lower-level account holders and investigating any suspicious input submitted through the SSL-host management, account-modification, or Multilang-related functions named in the advisory.

Because cPanel & WHM sits underneath such a large share of the shared and reseller hosting market, the practical impact of this disclosure will depend heavily on how quickly providers push the update out — and how many smaller operators are still running outdated, internet-exposed WHM panels by the time attackers start probing for them.

Read Time:3 Minute, 4 Second

Citrix NetScaler’s difficult year is getting harder. Separately from the patched SAML denial-of-service flaw tracked as CVE-2026-88779, security firm watchTowr says it uncovered two additional, previously undisclosed remote-code-execution vulnerabilities in NetScaler appliances while conducting forensic investigations — and that both appear to have already been exploited in real-world attacks.

What watchTowr Is ReportingAccording to watchTowr, the two flaws surfaced during incident-response engagements rather than through routine security research, which is itself a signal worth taking seriously: forensic investigators typically find this class of bug because they’re already looking at compromised systems, not because they went hunting for theoretical weaknesses. The firm describes both issues as capable of remote code execution, a far more serious outcome than the denial-of-service impact Citrix has confirmed for this week’s patched SAML bug.

As of publication, Citrix had not issued a security advisory covering these two flaws, had not assigned CVE identifiers, and had not confirmed affected build ranges, exploitation prerequisites, or available patches. That absence of vendor confirmation is an important caveat: watchTowr’s report should currently be treated as a credible warning from a respected research firm rather than a fully established, vendor-verified disclosure. Security teams should still act on it, but with the understanding that key technical details may still change once Citrix responds.

Why the Timing Is ConcerningThese reports land in the same week Citrix pushed emergency patches for the SAML authentication zero-day, and shortly after administrators spent days dealing with NetScaler appliances rebooting unexpectedly following an earlier patch cycle. Taken together, the pattern suggests NetScaler has drawn sustained attention from multiple independent researchers and threat actors simultaneously — the kind of scrutiny that tends to surface additional bugs in the same codebase once one flaw opens the door to deeper analysis.

NetScaler’s track record over the past several years, including previous high-profile incidents such as CitrixBleed, has already established the platform as a recurring target for both opportunistic scanners and more capable adversaries, precisely because NetScaler appliances typically sit at the network edge handling VPN access, load balancing, and authentication for an entire organization. A remote-code-execution flaw in that position is about as high-value a target as exists in enterprise infrastructure.

What Remains UnknownWhich NetScaler versions or configurations are affected

Whether the two new flaws require authentication or any specific feature to be enabled

Whether exploitation has been limited to narrow, targeted attacks or broader scanning activity

When Citrix will issue an advisory, CVE numbers, or a patch

Until Citrix responds directly, organizations are left weighing a credible but not yet fully substantiated warning against the operational reality of running internet-facing infrastructure that has already been targeted repeatedly this year.

Recommended Steps for Security TeamsInventory every NetScaler ADC and Gateway instance across the organization, including any that may have been overlooked in prior patch cycles.

Reduce public exposure of management interfaces wherever possible, and restrict administrative access to trusted networks only.

Preserve logs and relevant forensic evidence now, rather than after a confirmed compromise — if these flaws are later confirmed, early evidence will be far more valuable than anything collected retroactively.

Review authentication events, session activity, configuration changes, running processes, and outbound network traffic for anomalies consistent with the kind of access an RCE flaw would grant.

Organizations unable to mitigate exposure quickly may need to consider temporarily isolating affected appliances under an approved business-continuity plan.

Monitor Citrix’s official security bulletin channel closely, since authoritative guidance — including CVE numbers and patches — is still pending.

Secure Bulletin will continue following this story and will update coverage once Citrix issues an official advisory or confirms watchTowr’s findings.