[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"landing-trending":3,"cve-CVE-2022-39395":85,"landing-articles":158},{"count":4,"next":5,"previous":6,"results":7},266,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&sorted_by=-published_at",null,[8,16,20,30,34,42,50,59,70,79],{"id":4,"title":9,"summary":10,"published_at":11,"severity":12,"vendor":13,"products":14},"Google Brotli decoder - Remote Code Execution via compressed requests (Exploitation Check)","This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nTwo situations are possible. When the decoding is done by your own application or reverse proxy, identify the component and update it. If an update is not possible right away, reject requests with \"Content-Encoding: br\" at the reverse proxy or WAF.\r\n\r\nWhen the asset is hosted on a managed platform or behind a CDN (for example Platform.sh, Upsun or Fastly), the decoding may be done by the provider's edge router, in front of your application. You cannot patch it yourself, but this router handles all the traffic of your site. Ask your provider to confirm that its edge components are patched against CVE-2026-111497. Assets hosted on a managed platform or behind a CDN carry the tag \"paas: platform.sh\" or \"cdn: fastly\" in the asset view: for these assets, the Brotli decoding is done by the provider's edge router, in front of your application, and only the provider can patch it.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nContact your edge provider about the status of the pathing (Fastly \u002F Plateform.sh)\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.","2026-10-24T10:37:22.192753Z",4,"google",[15],"brotli",{"id":17,"title":9,"summary":18,"published_at":11,"severity":12,"vendor":13,"products":19},265,"This control is the second step of the Patrowl response to CVE-2026-111497 (Node2Shell). It complements the first control of 22 October 2026, which focused on the Node.js runtime, and does not replace it.\r\n\r\nWhy a second control\r\n\r\nCVE-2026-111497 is an out-of-bounds write in the Google Brotli decoder, the library that decompresses Brotli (\"br\") data. It was first published as a Node.js vulnerability, because Node.js bundles this decoder. Later publications showed that the flaw is in the library itself. Every product that embeds an affected version of the decoder is concerned, whatever its language or vendor. A public proof of concept demonstrates code execution.\r\n\r\nAny server that decompresses request bodies sent with \"Content-Encoding: br\" exposes the decoder to unauthenticated attackers. Known cases include Express 5 and NestJS 11 on Node.js, Koa and Fastify setups, Bun, Envoy and Istio with request decompression enabled, and any application or reverse proxy that decodes Brotli request bodies with an affected library.\r\n\r\nThe flaw also works in the other direction. A malicious server can compromise an unpatched client that decodes a Brotli response, for example Node.js fetch(), Python clients (requests, httpx, aiohttp, Scrapy) with the Brotli or brotlicffi package, or libcurl builds with Brotli support.\r\n\r\nWhat this control checks\r\n\r\nPatrowl sends small, valid Brotli-compressed requests to each asset and observes whether the server decodes them. The check does not depend on the technology: it detects the behaviour, whatever the stack behind it. These requests are what any legitimate client could send. They never reach the vulnerable code path and cannot affect the availability of the service.\r\n\r\nHow to read the result\r\n\r\nPotentially impacted means the asset decodes Brotli request bodies: the attack surface is exposed. It does not confirm that the asset is vulnerable. The version of the Brotli decoder in use is not visible from the outside.\r\n\r\nThis check covers applications that parse request bodies on their root path. A Not impacted result does not rule out exposure on other routes, nor on the client side. Checking the versions on the servers remains the only exhaustive verification.\r\n\r\nAffected and fixed versions\r\n\r\nGoogle Brotli 1.0.3 to 1.2.0 are affected, fixed in 1.0.10, 1.1.1 and 1.2.1. Fixed releases of the main products embedding it: Node.js 22.23.4, 24.22.1 and 26.12.1 (end-of-life lines 20.x and older and 25.x receive no fix), Bun 1.4.4, Envoy 1.37.8, 1.38.6, 1.39.3 and 1.40.0, Istio 1.29.9, 1.30.6 and 1.31.2, Python Brotli 1.2.1 and brotlicffi 1.2.1.0. Products that link against the system library depend on the Brotli package of the Linux distribution.\r\n\r\nRecommendations\r\n\r\nUpdate every component that embeds the Brotli decoder (only real fix). Start with the assets flagged by this control. Restart the processes after the update. Rebuild containers, single-executable applications and appliances that bundle an affected runtime or library.\r\n\r\nReduce the exposure until the update is deployed. Reject requests with \"Content-Encoding: br\" at the reverse proxy, load balancer or WAF, case-insensitively and including lists such as \"gzip, br\". On Envoy and Istio, disable request decompression for Brotli.\r\n\r\nReview outbound calls. List the features that fetch content from servers you do not control, and patch the services that host them first.",[15],{"id":21,"title":22,"summary":23,"published_at":24,"severity":12,"vendor":25,"products":26},263,"Oracle Java SE JSSE - Improper Access Control & Unauthorized Data Access & Unauthorized Data Modification","Oracle Java SE is the Java runtime and development platform. Its JSSE (Java Secure Socket Extension) component provides TLS\u002FSSL for secure network communication. Oracle GraalVM is a JDK distribution based on the same platform.\r\n\r\nCVE-2026-91403\r\n\r\nA vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition can be exploited by an unauthenticated attacker with network access over multiple protocols. A successful attack can give unauthorized access to critical data and allow unauthorized creation, deletion or modification of data. It can also affect sandboxed Java Web Start applications and applets that run untrusted code. The record lists the weakness as CWE-284 (Improper Access Control) in the CISA ADP entry, while another database lists CWE-295. The record lists these affected versions:\r\n- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1.\r\n- Oracle GraalVM for JDK: 17.0.21, 21.0.13.\r\n- Oracle GraalVM Enterprise Edition: 21.3.20.\r\n\r\nOracle published an out-of-cycle Security Alert on October 21, 2026. One secondary source says the fix makes Java distrust eight compromised intermediate CA certificates shipped with the JDK. The Oracle-focused sources do not confirm this root cause, so check it against the Oracle advisory. CISA ADP SSVC data shows Exploitation: none, Automatable: yes, Technical Impact: total. The CVE is not in the CISA KEV catalog as of October 22, 2026, and its EPSS score is below 1%.","2026-10-23T14:12:32.871954Z","Oracle",[27,28,29],"Oracle Java SE","Oracle GraalVM Enterprise Edition","Oracle GraalVM for JDK",{"id":31,"title":22,"summary":32,"published_at":24,"severity":12,"vendor":25,"products":33},264,"Patrowl scan limitation — this vulnerability cannot be detected by network scanning. The problem is not in a service exposed on the network, but in the list of trusted certificates built into Java — and nothing a scanner can see from the outside tells it which certificates a system accepts, or even whether the system is running Java at all. The only way to test for it from the network would be to use a fraudulent certificate during a secure connection, which is a real attack rather than a scan, and it would still miss most cases. The only reliable way to detect this vulnerability is to check locally which Java versions are installed and compare them with the list of affected versions.\r\n\r\nOracle Java SE is the Java runtime and development platform. Its JSSE (Java Secure Socket Extension) component provides TLS\u002FSSL for secure network communication. Oracle GraalVM is a JDK distribution based on the same platform.\r\n\r\nCVE-2026-91403\r\n\r\nA vulnerability in the JSSE component of Oracle Java SE, Oracle GraalVM for JDK and Oracle GraalVM Enterprise Edition can be exploited by an unauthenticated attacker with network access over multiple protocols. A successful attack can give unauthorized access to critical data and allow unauthorized creation, deletion or modification of data. It can also affect sandboxed Java Web Start applications and applets that run untrusted code. The record lists the weakness as CWE-284 (Improper Access Control) in the CISA ADP entry, while another database lists CWE-295. The record lists these affected versions:\r\n- Oracle Java SE: 8u511, 8u511-perf, 11.0.33, 17.0.21, 21.0.13, 25.0.5, 27.0.1.\r\n- Oracle GraalVM for JDK: 17.0.21, 21.0.13.\r\n- Oracle GraalVM Enterprise Edition: 21.3.20.\r\n\r\nOracle published an out-of-cycle Security Alert on October 21, 2026. One secondary source says the fix makes Java distrust eight compromised intermediate CA certificates shipped with the JDK. The Oracle-focused sources do not confirm this root cause, so check it against the Oracle advisory. CISA ADP SSVC data shows Exploitation: none, Automatable: yes, Technical Impact: total. The CVE is not in the CISA KEV catalog as of October 22, 2026, and its EPSS score is below 1%.",[27,28,29],{"id":35,"title":36,"summary":37,"published_at":38,"severity":12,"vendor":39,"products":40},260,"XWiki Platform - Unauthenticated Remote Code Execution via SolrSearch Template Injection","XWiki Platform is an open-source enterprise wiki and application platform written in Java, offering runtime services for building collaborative applications on top of it.\r\n\r\nCVE-2025-24893\r\n\r\nInsufficient neutralization of directives in dynamically evaluated code (CWE-95, eval injection) in the SolrSearch macro allows any unauthenticated guest to perform arbitrary remote code execution through a specially crafted request to SolrSearch (e.g. \u003Chost>\u002Fxwiki\u002Fbin\u002Fget\u002FMain\u002FSolrSearch?media=rss&text=...), injecting and executing arbitrary Groovy code via template injection. This impacts the confidentiality, integrity, and availability of the entire XWiki installation. Affected versions are XWiki Platform from 5.3-milestone-2 up to (but excluding) 15.10.11, and from 16.0.0-rc-1 up to (but excluding) 16.4.1. The flaw was patched in XWiki 15.10.11, 16.4.1, and 16.5.0RC1; users unable to upgrade can mitigate it by editing Main.SolrSearchMacros (line 955 in SolrSearchMacros.xml) to match the rawResponse macro in macros.vm#L2824 with a content type of application\u002Fxml. The vulnerability has been actively exploited in the wild, including a two-stage attack chain delivering a coinminer, although it is not in the CISA KEV catalog.","2026-10-23T08:48:16.092785Z","XWiki",[41],"XWiki Platform",{"id":43,"title":44,"summary":45,"published_at":46,"severity":12,"vendor":47,"products":48},262,"Arista VeloCloud Orchestrator - Authenticated SQLi to Privilege Escalation","VeloCloud Orchestrator (VCO) is the central management and orchestration platform for Arista VeloCloud SD-WAN. It is used to configure and monitor edges, gateways, and enterprise tenants.\r\n\r\nCVE-2026-114625\r\n\r\nA security issue in VeloCloud Orchestrator On-Prem lets a remote, authenticated attacker reach privileged internal functionality and affect the VCO host. Any authenticated user can gain operator privileges and act as a local \"superuser operator\". The minimum role needed is Enterprise Read Only. The web interface is exposed by default and no configuration prevents the exposure. The weakness is mapped to CWE-89 (SQL Injection) and CAPEC-66. CISA ADP SSVC lists exploitation as \"none\", automatable as \"no\", and technical impact as \"total\". Secondary sources disagree on whether it is being exploited, so check Arista's advisory directly. Affected on-prem versions are 5.2.0 before 5.2.3.18, 6.1.0 before 6.1.3.10, and 6.4.0 before 6.4.2.12. Hosted and Dedicated VCO deployments were also affected but have already been patched. The fix is to upgrade to 5.2.3.18, 6.1.3.10, 6.4.2.12 or later. Until then, restrict web interface access to trusted administrative networks and monitor for suspicious activity.","2026-10-23T07:57:12.173417Z","Arista Networks",[49],"VeloCloud Orchestrator",{"id":51,"title":52,"summary":53,"published_at":54,"severity":12,"vendor":55,"products":56},261,"Portainer - Standard user can bypass the bind-mount restriction and take over the Docker host","Portainer is a lightweight service delivery platform for containerized applications, used to manage Docker, Swarm, Kubernetes and ACI environments through a web UI and an API proxy that can enforce per-environment security restrictions for non-administrator users.\r\n\r\nGHSA-j3mf-q9qf-5qf8\r\n\r\nImproper input validation in the Compose stack validator IsValidStackFile (api\u002Fstacks\u002Fstackutils\u002Fvalidation.go): when the per-environment setting \"Hide bind mounts for non-administrators\" is enabled, the validator rejected bind mounts declared in top-level volumes and each service's volumes, but never inspected a service's volumes_from field. By declaring volumes_from pointing at an existing container, any authenticated Standard user with stack-management access to a Docker standalone environment inherits all of that container's mounts — including host bind mounts. Since the documented Portainer Server\u002FAgent deployments mount the Docker socket, an attacker can gain full control of the host Docker daemon (and from there root on the host), or read Portainer's own database and stored credentials by inheriting the Server's data directory. Affected versions: ≥ 2.39.0 ≤ 2.39.8 and ≥ 2.40.0 ≤ 2.45.2 (both editions; Swarm stacks not affected). Fixed in 2.45.3, released 2026-10-22; no patch for 2.39.x or EOL 2.40.x–2.44.x — upgrade to 2.45.3. Interim mitigations: disable stack usage for non-administrators, restrict standard-user environment access, and audit existing non-administrator stacks for volumes_from. No CVE ID had been assigned at publication time.","2026-10-23T07:54:21.608453Z","Portainer",[57,58],"Portainer Community Edition","Portainer Business Edition",{"id":60,"title":61,"summary":62,"published_at":63,"severity":12,"vendor":64,"products":65},258,"Multiple Vulnerabilities in Cisco Unified Communications Products - Injection & Authentication Bypass","Cisco Unified Communications Manager and its companion products (Emergency Responder, Unity Connection, IM & Presence, SME, Prime Collaboration Deployment) form Cisco's enterprise VoIP and collaboration platform, providing call control, emergency call routing, voicemail, and presence services for enterprise telephony networks.\r\n\r\nCVE-2026-76473\r\n\r\nImproper control of a resource through its lifetime (CWE-74, injection-related) in multiple Cisco voice products, including Cisco Emergency Responder, Unified CM, Unified CM IM & Presence Service, and Unity Connection. It is remotely exploitable with no privileges or user interaction required, and can result in full compromise of confidentiality, integrity, and availability (CVSS 9.8). Affected releases include Emergency Responder, Unified CM, IM & Presence, and Unity Connection versions 14 and 15 (14 through 14SU6, and 15 through 15SU4 and their maintenance releases). Cisco addressed the flaw in its October 2026 Unified Communications Products Security Hardening Release, which groups several internally discovered vulnerabilities fixed during a comprehensive security review. (Strix CVE entry, NHS Digital alert)\r\n\r\nCVE-2026-76474\r\n\r\nImproper authentication (CWE-287) affecting the same set of Cisco voice products. The flaw covers authentication bypass and session-fixication-style weaknesses; a remote, unauthenticated attacker without user interaction can fully compromise the affected system (CVSS 9.8). The same product versions are affected (Emergency Responder, Unified CM, Unified CM IM & Presence Service, and Unity Connection releases 14.x and 15.x up to 14SU6 \u002F 15SU4). It was disclosed alongside the other flaws in Cisco's October 2026 security hardening release, and customers should upgrade to the fixed hardening releases listed in the vendor advisory. (Strix CVE entry, Security Online)","2026-10-22T14:31:16.035692Z","Cisco",[66,67,68,69],"Cisco Emergency Responder","Cisco Unified Communications Manager","Cisco Unity Connection","Cisco Unified CM IM & Presence Service (IM&P)",{"id":71,"title":72,"summary":73,"published_at":74,"severity":12,"vendor":75,"products":76},259,"Node.js (bundled Brotli) - Out-of-Bounds Write & Remote Code Execution","Node.js is a cross-platform JavaScript runtime built on V8, widely used for server-side web applications and APIs. Google Brotli is a lossless compression library whose decoder Node bundles in deps\u002Fbrotli and exposes through node:zlib; compressed HTTP responses (including Brotli Content-Encoding) are automatically decompressed by fetch() and frameworks such as Express 5.\r\n\r\nCVE-2026-111497\r\n\r\nAn out-of-bounds write in the Brotli decoder (c\u002Fdec\u002Fdecode.c) bundled with Node.js. When a Node.js process decodes a malformed Brotli-compressed stream from an attacker — for example an HTTP response body auto-decompressed via fetch(), Express 5, or node:zlib — the decoder fails to validate input boundaries and writes past buffer limits, which the Node.js project says can permit remote code execution (memory disclosure and arbitrary code execution). The same flaw exists in upstream Google Brotli versions 1.0.3 through 1.2.0. It affects the Node.js 22.x, 24.x, and 26.x release lines; end-of-life lines (e.g. 20.x, 25.x) receive no fix and are stated to be \"always affected\". Fixed in Node.js v22.23.4, v24.22.1, and v26.12.1 (October 21, 2026), based on upstream Brotli commit 0ed4268 (\"Detect and report invalid stream earlier\", Evgenii Kliuchnikov, Google). Upstream Brotli shipped fixes in 1.2.1, 1.1.1, and 1.0.10. No workaround is documented; users should upgrade Node and restart all Node processes, and rebuild any containers, single-executable apps, or appliances that bundle a Node binary. Distro packages linked against a system Brotli library depend on the distro's brotli package instead.","2026-10-22T14:08:04.199100Z","Node.js",[77,78],"Node.js runtime","Google Brotli",{"id":80,"title":81,"summary":82,"published_at":83,"severity":12,"vendor":55,"products":84},257,"Portainer - Query Parameter Confusion in Kubernetes Shell Leading to Arbitrary Command Execution in Any Pod","Portainer is a web-based container and Kubernetes management platform that provides GUI-driven administration of Docker, Swarm, and Kubernetes environments, including a browser-based kubectl shell for Kubernetes clusters managed through the Portainer Agent.\r\nGHSA-7423-r5wh-26x7\r\nImproper handling of extra parameters (CWE-235) combined with incorrect authorization (CWE-863) in the Kubernetes shell WebSocket handler (api\u002Fhttp\u002Fhandler\u002Fwebsocket\u002Fshell_pod.go). When a user opens the kubectl shell, the Portainer server creates a short-lived shell Pod and rewrites the WebSocket request to target it via the Agent's Pod-exec endpoint. The rewrite used Query().Add() to append the server-chosen namespace, podName, containerName, and command values instead of replacing them, while the Agent resolves each parameter by its first occurrence — so an authenticated standard-role user could supply duplicate query parameters and redirect the exec to any Pod and command of their choosing. On Agent-managed and Edge-Agent-managed Kubernetes environments the exec runs under the Agent's in-cluster service account, which the published manifest binds to cluster-admin, so the attacker obtains arbitrary command execution in any Pod in any namespace, full disclosure of cluster Secrets, and potential compromise of the Agent itself; Kubernetes RBAC provides no mitigation. Affected versions: >= 2.39.0 and \u003C 2.39.6 (2.39.x LTS) and all versions prior to 2.45.0, since the flawed behavior was introduced with the kubectl shell feature in 2.9.0. Fixed in 2.39.6 (LTS backport) and 2.45.0 (LTS); the 2.40–2.44 short-term support lines receive no dedicated patch. Local Kubernetes connections are not affected. Reported by D0HY30N on 2026-07-30; no CVE ID has been assigned as of publication. (Source: GitHub Security Advisory GHSA-7423-r5wh-26x7)","2026-10-22T09:12:41.197853Z",[55],{"id":86,"cve_id":87,"euvd_id":88,"summary":89,"published":90,"cvss_data":91,"is_remote":102,"cwes":103,"cpes":105,"technologies":109,"references":113,"score":126,"epss_score":127,"epss_percentile":128,"is_kev":129,"cisa_kev_date_added":6,"cisa_kev_due_date":6,"cisa_ssvc":130,"attack_mappings":140,"exploits":157},311490,"CVE-2022-39395","EUVD-2022-7245","Vela Insecure Defaults\n\n### Impact\nSome current default configurations for Vela allow exploitation and container breakouts.\n\n#### Default Privileged Images\n\nRunning Vela plugins as privileged Docker containers allows a malicious user to easily break out of the container and gain access to the worker host operating system. On a fresh install of Vela without any additional configuration, the `target\u002Fvela-docker` plugin will run as a privileged container, even if the Vela administrators did not intend to allow for any privileged plugins, and even if the `vela.yml` configuration file does not use the `privileged = True` flag.\n\nPrivileged containers permit trivial breakouts, which can pose significant risk to the environment in which Vela is running.\n\n#### Default Allowed Repositories\n\nOn a fresh install of Vela, anyone with a GitHub account (or other enabled source control management solution) is allowed to enable a repository within Vela and run builds. This means that, if a Vela instance is accessible to the public, a third party could add their own malicious repos to the Vela instance and run arbitrary code.\n\nAn example of a publicly accessible Vela instance would be one not protected behind a VPN. Whether Vela is publicly accessible depends on how Vela is set up, NOT how it is connected to GitHub.\n\n#### Default Enabled Events allows Pull Requests\n\nBy default, Vela currently enables pull request events when a repository is Vela-enabled. Unless this default was changed when enabling each repository, anyone who can issue a pull request against a repository can trigger a Vela job.\n\nThis not only permits a third party to run arbitrary code in a Vela environment, but also poses an additional risk when secrets within Vela are configured to be available in pull requests, permitting anyone with access to create pull requests to access these secrets.\n\n### Patches\n\nUpgrade to 0.16.0 or later. After upgrading, Vela administrators will need to explicitly change the default settings to configure Vela as desired.\n\nSome of the fixes will interrupt existing workflows and will require Vela administrators to modify default settings (see release notes for more information). However, not applying the patch (or workarounds) will continue existing risk exposure.\n\n### Workarounds\n\n#### Default Privileged Images\n\nInstead of upgrading, the Vela administrators can adjust the worker's `VELA_RUNTIME_PRIVILEGED_IMAGES` setting to be explicitly empty:\n\n`VELA_RUNTIME_PRIVILEGED_IMAGES=\"\"`\n\nBy assigning `VELA_RUNTIME_PRIVILEGED_IMAGES` to an empty value it disallows any images from running as privileged containers in Vela.\n\n#### Default Allowed Repositories\n\nInstead of upgrading, the Vela administrators can leverage the `VELA_REPO_ALLOWLIST` setting on the server component to restrict access to a list of repositories that are allowed to be enabled.\n\nBy changing it from the default empty list (currently interpreted by Vela as \"all repositories\") to a list explicitly allowing specific repositories, Vela administrators can control what repositories are allowed to be enabled in Vela.\n\nVela's current default list of approved repositories that can be added to a Vela instance is an empty list. However this is currently interpreted as allowing all repositories.\n\nIn the updated version, a null value (the empty list) will be interpreted as permitting no repositories to be added to a Vela instance.\n\n#### Default Enabled Events allows Pull Requests\n\nAudit enabled repositories and disable `pull_requests` if they are not needed.\n\nInstead of upgrading, the pull request trigger can be disabled on a per-repository basis.\n\nAdditional protection can be provided by preventing unauthorized users from submitting pull requests in GitHub (or other source control management solution).\n\n### Residual Risk\n\n#### Default Privileged Images\n\nAfter applying the update, any repos that Vela administrators manually define as \"trusted repos\" will be able to run the manually-specified images that are allowed to run as privileged. Those repos will continue to be vulnerable to breakout, but applying the update will help protect against the risk of trivial breakout arising from an image running as a privileged container.\n\nThe recommendation is to utilize plugins that do not require privileged capabilities.\n\nFor example, utilize `target\u002Fvela-kaniko` instead of `target\u002Fvela-docker` as the Kaniko plugin does not require privileged access.\n\n#### Default Allowed Repositories\n\nApplying this update (or workaround) will protect against the risk of Vela interpreting the default empty list of approved repositories as \"all repositories\" rather than \"no repositories\" (the current default).\n\n#### Default Enabled Events allows Pull Requests\n\nSince this change only impacts newly enabled repositories, the update will not address the risk to existing enabled repositories resulting from Vela enabling pull request events when a repository is Vela-enabled.\n\nAdditionally, this change only impacts defaults; users can still configure their repositories to allow pull requests as triggering events.\n\nIn order to monitor risk going forward, refer to the `Workaround` section with the heading `Default Enabled Events allows Pull Requests`.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Email us at [vela@target.com](mailto:vela@target.com)\n\nAffected products: `go-vela\u002Fworker`, `go-vela\u002Fserver`, `go-vela\u002Fui`, `go-vela\u002Fdocumentation`","2022-11-09T19:17:00Z",{"cvss_v3.1":92},{"scope":93,"version":94,"baseScore":95,"attackVector":96,"baseSeverity":97,"vectorString":98,"integrityImpact":99,"userInteraction":100,"attackComplexity":101,"availabilityImpact":99,"privilegesRequired":101,"confidentialityImpact":99},"CHANGED","3.1",9.9,"NETWORK","CRITICAL","CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:L\u002FUI:N\u002FS:C\u002FC:H\u002FI:H\u002FA:H","HIGH","NONE","LOW",true,[104],"CWE-269",[106,107,108],"cpe:2.3:a:go-vela:worker:*:*:*:*:*:*:*:*","cpe:2.3:a:go-vela:server:*:*:*:*:*:*:*:*","cpe:2.3:a:go-vela:ui:*:*:*:*:*:*:*:*",[110,111,112],"Go-Vela Worker","Go-Vela Ui","Go-Vela Server",[114,115,116,117,118,119,120,121,122,123,124,125],"https:\u002F\u002Fdocs.docker.com\u002Fengine\u002Fsecurity\u002F#docker-daemon-attack-surface","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fserver\u002Fcommit\u002F05558ee99d70f7d6f83bed7c8f78ac0b35fa26f4","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fserver\u002Freleases\u002Ftag\u002Fv0.16.0","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fserver\u002Fsecurity\u002Fadvisories\u002FGHSA-5m7g-pj8w-7593","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fui\u002Freleases\u002Ftag\u002Fv0.17.0","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fui\u002Fsecurity\u002Fadvisories\u002FGHSA-xf39-98m2-889v","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fworker\u002Freleases\u002Ftag\u002Fv0.16.0","https:\u002F\u002Fgithub.com\u002Fgo-vela\u002Fworker\u002Fsecurity\u002Fadvisories\u002FGHSA-2w78-ffv6-p46w","https:\u002F\u002Fgo-vela.github.io\u002Fdocs\u002Finstallation\u002Fserver\u002Freference\u002F#vela_repo_allowlist","https:\u002F\u002Fgo-vela.github.io\u002Fdocs\u002Finstallation\u002Fworker\u002Freference\u002F#vela_runtime_privileged_images","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2022-39395","https:\u002F\u002Fpkg.go.dev\u002Fvuln\u002FGO-2022-1100",0.7,0.01198,0.67908,false,{"timestamp":131,"automatable":132,"tech_impact":133,"exploitation":134,"cisa_decision":135,"cisa_remediation_timeline":139},"2025-04-23T15:46:53.128029Z","no","total","none",{"vector":136,"decision":137,"priority":138},"CISAv1\u002FE:N\u002FA:N\u002FT:T\u002FM:H\u002F2026-10-25T20:07:13.664495\u002F","track_star","medium","14D",[141,147],{"name":142,"source":143,"tactics":144,"technique_id":146},"Exploit Public-Facing Application","attack_vector",[145],"initial-access","T1190",{"name":148,"source":149,"cwe_ids":150,"tactics":151,"capec_ids":153,"technique_id":156},"Abuse Elevation Control Mechanism","capec",[104],[152],"privilege-escalation",[154,155],"CAPEC-122","CAPEC-233","T1548",[],{"count":159,"next":160,"previous":6,"results":161},30,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&sorted_by=-published_at",[162,169,177,185,192,199,206,211,218,225],{"id":159,"title":163,"summary":164,"published_at":165,"type":166,"link":167,"image_url":168},"PHP2Shell: Two Critical RCE Flaws in PHP (CVSS 9.2)","Unauthenticated code execution demonstrated on WordPress, Drupal and Joomla, and reproduced in our lab. Patched versions and steps to take today.","2026-10-22T00:00:00Z","cve","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002Fc0615c4ee6-1792684469\u002Fphp2shell-2-critical-rce-flaws-php-cvss-9-2.png",{"id":170,"title":171,"summary":172,"published_at":173,"type":174,"link":175,"image_url":176},29,"Manage External Security Across All Your Entities","Centralize the management of entities, users and external security resources while maintaining strict data isolation with Patrowl.","2026-09-15T00:00:00Z","security tips","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fmulti-entity-external-security-how-structure-governance-group-level","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F8b2c0cc5eb-1789551467\u002Fvisu_1_multi_tenancy_dark_1x.webp",{"id":178,"title":179,"summary":180,"published_at":181,"type":182,"link":183,"image_url":184},28,"Will AI Become the Next Hacker? Bruce Schneier Answers at DEF CON 34","Tax law, finance, legislation: Bruce Schneier shows how AI could hack human rule systems just as easily as it hacks software.","2026-09-14T00:00:00Z","hacks","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fbruce-schneier-def-con-34","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F5c616d9db4-1789462598\u002Fai-hacker.en.png",{"id":186,"title":187,"summary":188,"published_at":189,"type":174,"link":190,"image_url":191},27,"Exposure Management: definition, stakes, and how it works","Vulnerabilities, misconfigurations, poorly managed identities: understand what Exposure Management is and why it matters in 2026.","2026-09-10T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fdefinition-exposure-management","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F06170638a9-1789050834\u002Fexposure.management.definition.en.png",{"id":193,"title":194,"summary":195,"published_at":196,"type":182,"link":197,"image_url":198},26,"DGFiP Cyberattack 2026: Inside the Attacker","Two distinct attacks hit France","2026-08-17T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fdgfip-cyberattack-2026-inside-attacker-mind","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002Fdc38d33696-1787055371\u002Fdgfip-2026.png",{"id":200,"title":201,"summary":202,"published_at":203,"type":166,"link":204,"image_url":205},25,"CVE-2026-64638: XSS2Shell, a WordPress Login Vulnerability","Pre-auth XSS on wp-login.php, patched August 6. What is actually exploitable, and how to read it in your Patrowl report.","2026-08-10T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fxss2shell-critical-wordpress-login-vulnerability-2026","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F904e61748b-1786369212\u002Fxss2shell.png",{"id":207,"title":208,"summary":208,"published_at":203,"type":166,"link":209,"image_url":210},24,"CVE-2026-64638 : XSS2Shell, faille du login WordPress","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fcve-2026-64638-xss2shell-faille-login-wordpress","",{"id":212,"title":213,"summary":214,"published_at":215,"type":166,"link":216,"image_url":217},23,"How Agentic AI Hunts Down CVEs Before Attackers Do","38 vulnerability sources monitored around the clock, pentester-validated proof of exploitability, an alert within hours. See how it works.","2026-08-05T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fproactive-threat-hunting-agentic-ai-cve","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F804988ce7b-1785930160\u002Fproactive-threat-hunting-how-agentic-ai-tracks-cves.png",{"id":219,"title":220,"summary":221,"published_at":222,"type":182,"link":223,"image_url":224},22,"AI Agent Incident: OpenAI HuggingFace — Risks and Lessons","An autonomous AI agent escaped its sandbox via a JFrog Artifactory zero-day, compromised HuggingFace via privilege escalation and stolen credentials. Reconstructed timeline and security lessons.","2026-07-31T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fai-agent-incident-openai-huggingface-risks","[Image URL from Kirby]",{"id":226,"title":227,"summary":228,"published_at":229,"type":174,"link":230,"image_url":231},21,"SaaS Under Watch: What Your SDLC Doesn","Your pipeline is green. Your real exposure may have changed without you knowing it. The complete guide for software vendors.","2026-07-29T00:00:00Z","https:\u002F\u002Fpatrowl.io\u002Fen\u002Fblog\u002Fsecuring-saas-application-software-vendor","https:\u002F\u002Fpatrowl.io\u002Fmedia\u002Fsite\u002F20d6ec0cd0-1785331401\u002Fapplication-security.png"]