[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"landing-trending":3,"cve-CVE-2021-43846":30,"landing-articles":211},{"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":49,"technologies":182,"references":185,"score":192,"epss_score":193,"epss_percentile":194,"is_kev":195,"cisa_kev_date_added":6,"cisa_kev_due_date":6,"cisa_ssvc":196,"attack_mappings":202,"exploits":209},279897,"CVE-2021-43846","EUVD-2022-0611","CSRF forgery protection bypass in solidus_frontend\n\n### Impact\nCSRF vulnerability that allows a malicious site to add an item to the user's cart without their knowledge.\n\nAll `solidus_frontend` versions are affected. If you're using your own storefront, please, follow along to make sure you're not affected.\n\nTo reproduce the issue:\n\n- Pick the id for a variant with available stock. From the rails console:\n\n  ```ruby\n  Spree::Variant.in_stock.pluck(:id)\n  ```\n\n  Say we pick variant id `2`.\n\n- Launch your application, for instance, on `http:\u002F\u002Flocalhost:3000`:\n\n  ```bash\n  bin\u002Frails server\n  ```\n\n- Open your browser dev tools.\n\n- Click on whatever link in your store.\n\n- Copy the value of the `Cookie` request header sent for the previous request from your browser dev tools.\n\n- Execute the following, using your previously selected variant id and the value of the `Cookie` header (notice how it doesn't contain any authentication token):\n\n  ```bash\n  curl -X POST -d \"variant_id=2&quantity=1\" -H \"Cookie: guest_token=eyJfcmFpbHMiOnsibWVzc2FnZSI6IklrWlRVMWRQWnpKMVZVdFNXRzlPVW1aaWJHTjZZa0VpIiwiZXhwIjpudWxsLCJwdXIiOiJjb29raWUuZ3Vlc3RfdG9rZW4ifX0%3D--5006ba5d346f621c760a29b6a797bf351d17d1b8; _sandbox_session=vhutu5%2FL9NmWrUpGc3DxrFA%2FFsQD1dHn1cNsD7nvE84zcjWf17Af4%2F%2F2Vab3md71b6KTb9NP6WktdXktpwH4eU01jEGIBXG5%2BMzW5nL0nb4W269qk1io4LYljvoOg8%2BZVll7oJCVkJLKKh0sSoS0Kg8j%2FCHHs%2BsShohP%2BGnA%2Bfr9Ub8H6HofpSmloSpsfHHygmX0ho03fEgzHJ4DD5wJctaNKwg7NhVikHh5kgIPPHl84OGCgv3p2oe9jR19HTxOKq7BtyvDd7XZsecWhkcfS8BPnvDDUWZG6qpAEFI5kWo81KkpSJ%2Bp6Q1HOo8%3D--n3G2vgaDG7VS%2B%2FhF--ZTjxBAkfGG3hpr4GRQ2S1Q%3D%3D; __profilin=p%3Dt\" http:\u002F\u002Flocalhost:3000\u002Forders\u002Fpopulate\n  ```\n\n- Reload your browser and look at how your cart got updated.\n\n### Patches\n\nPlease, upgrade `solidus` to versions `3.1.5`, `3.0.5` or `2.11.14`.\n\nAfter upgrading, make sure you read the \"Upgrade notes\"  section below.\n\n### Upgrade notes\n\nThe patch adds CSRF token verification to the \"Add to cart\" action. Adding forgery protection to a form that missed it can have some side effects.\n\n#### `InvalidAuthenticityToken` errors\n\nIf you're using the `:exception` strategy, it's likely that after upgrading, you'll see more `ActionController::InvalidAuthenticityToken` errors popping out in your logs. Due to browser-side cache, a form can be re-rendered and sent without any attached request cookie (for instance, when re-opening a mobile browser). That will cause an authentication error, as the sent token won't match with the one in the session (none in this case). That's a known problem in the Rails community (see https:\u002F\u002Fgithub.com\u002Frails\u002Frails\u002Fissues\u002F21948), and, at this point, there's no perfect solution.\n\nAny attempt to mitigate the issue should be seen at the application level. For an excellent survey of all the available options, take a look at https:\u002F\u002Fgithub.com\u002Fbetagouv\u002Fdemarches-simplifiees.fr\u002Fblob\u002F5b4f7f9ae9eaf0ac94008b62f7047e4714626cf9\u002Fdoc\u002Fadr-csrf-forgery.md. The latter is a third-party link. As the information is relevant here, we're going to copy it below, but it should be clear that all the credit goes to @kemenaran:\n\n> # Protecting against request forgery using CRSF tokens\n> \n> ## Context\n> \n> Rails has CSRF protection enabled by default, to protect against POST-based CSRF attacks.\n> \n> To protect from this, Rails stores two copies of a random token (the so-named CSRF token) on each request:\n> - one copy embedded in each HTML page,\n> - another copy in the user session.\n> \n> When performing a POST request, Rails checks that the two copies match – and otherwise denies the request. This protects against an attacker that would generate a form secretly pointing to our website: the attacker can't read the token in the session, and so can't post a form with a valid token.\n> \n> The problem is that, much more often, this has false positives. There are several cases for that, including:\n> \n> 1. The web browser (often mobile) loads a page containing a form, then is closed by the user. Later, when the browser is re-opened, it restores the page from the cache. But the session cookie has expired, and so is not restored – so the copy of the CSRF token stored in the session is missing. When the user submits the form, they get an \"InvalidAuthenticityToken\" exception.\n> \n> 2. The user attempts to fill a form, and gets an error message (usually in response to a POST request). They close the browser. When the browser is re-opened, it attempts to restore the page. On Chrome this is blocked by the browser, because the browser denies retrying a (probably non-idempotent) POST request. Safari however happily retries the POST request – but without sending any cookies (in an attempt to avoid having unexpected side-effects). So the copy of the CSRF token in the session is missing (because no cookie was sent), and the user get an \"InvalidAuthenticityToken\" exception.\n> \n> ## Options considered\n> \n> ### Extend the session cookie duration\n> \n> We can configure the session cookie to be valid for a longer time (like 2 weeks).\n> \n> Pros:\n> - It solves 1., because when the browser restores the page, the session cookie is still valid.\n> \n> Cons:\n> - Users would be signed-in for a much longer time by default, which has unacceptable security implications.\n> - It doesn't solve 2. (because Safari doesn't send any cookie when restoring a page from a POST request)\n> \n> ### Change the cache parameters\n> \n> We can send a HTTP cache header stating 'Cache-Control: no-store, no-cache'. This instructs the browser to never keep any copy of the page, and to always make a request to the server to restore it.\n> \n> This solution was attempted during a year in production, and solved 1. – but also introduced another type of InvalidAuthenticityToken errors. In that scenario, the user attempts to fill a form, and gets an error message (usually in response to a POST request). They then navigate on another domain (like France Connect), then hit the \"Back\" button. Crossing back the domain boundary may cause the browser to either block the request or retry an invalid POST request.\n> \n> Pros:\n> - It solves 1., because on relaunch the browser requests a fresh page again (instead of serving it from its cache), thus retrieving a fresh session and a fresh matching CSRF token.\n> \n> Cons:\n> - It doesn't solve 2.\n> - It causes another type of InvalidAuthenticityToken errors.\n> \n> ### Using a null-session strategy\n> \n> We can change the default protect_from_forgery strategy to :null_session. This makes the current request use an empty session for the request duration.\n> \n> Pros:\n> - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a stale form is submitted.\n> \n> Cons:\n> - The user is asked to sign-in only after filling and submitting the form, losing their time and data\n> - The user will not be redirected to their original page after signing-in\n> - It has potential security implications: as the (potentically malicious) request runs anyway, variables cached by a controller before the Null session is created may allow the form submission to succeed anyway (https:\u002F\u002Fwww.veracode.com\u002Fblog\u002Fmanaging-appsec\u002Fwhen-rails-protectfromforgery-fails)\n> \n> ### Using a reset-session strategy\n> \n> We can change the default protect_from_forgery strategy to :reset_session. This clears the user session permanently, logging them out until they log in again.\n> \n> Pros: \n> - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a stale form is submitted.\n> \n> Cons:\n> - A forgery error in a browser tab will disconnect the user in all its open tabs\n> - It has potential security implications: as the (potentically malicious) request runs anyway, variables cached by a controller before the Null session is created may allow the form submission to succeed anyway (https:\u002F\u002Fwww.veracode.com\u002Fblog\u002Fmanaging-appsec\u002Fwhen-rails-protectfromforgery-fails)\n> - It allows an attacker to disconnect an user on demand, which is not only inconvenient, but also has security implication (the attacker could then log the user on it's own attacker account, pretending to be the user account)\n> \n> ### Redirect to login form\n> \n> When a forgery error occurs, we can instead redirect to the login form.\n> \n> Pros:\n> - It kind of solves 1., by redirecting to a \"Please sign-in\" page when a stale form is submitted (but the user data is lost).\n> - It kind of solves 2., by redirecting to a \"Please sign-in\" page when a previously POSTed form is reloaded.\n> \n> Cons:\n> - Not all forms require authentication – so for public forms there is no point redirecting to the login form. \n> - The user will not be redirected to their original page after signing-in (because setting the redirect path is a state-changing action, and it is dangerous to let an unauthorized request changing the state – an attacker could control the path where an user is automatically redirected to.)\n> - The implementation is finicky, and may introduce security errors. For instance, a naive implementation that catches the exception and redirect_to the sign-in page will prevent Devise from running a cleanup code – which means the user will still be logged, and the CSRF protection is bypassed. However a well-tested implementation that lets Devise code run should avoid these pittfalls.\n> \n> ### Using a long-lived cookie for CSRF tokens\n> \n> Instead of storing the CSRF token in the session cookie (which is deleted when the browser is closed), we can instead store it in a longer-lived cookie. For this we need to patch Rails.\n> \n> Pros:\n> - It solves 1., because when the user submits a stale form, even if the session cookie because stale, the long-lived CSRF cookie is still valid.\n> \n> Cons:\n> - It doesn't solve 2., because when Safari retries a POST request, it sends none of the cookies (not even long-lived ones).\n> - Patching Rails may introduce security issues (now or in the future)\n\n#### Broken behavior due to session expiration + template cache\n\nAlthough pretty unlikely, you should make sure that your current setup for cache\u002Fsession expiration is compatible. The upgrade can break the addition of products to the cart if both:\n\n- The \"Add to cart\" form is being cached (usually along with the variant information).\n\n- A user session is reset at every or every few requests.\n\nThe token validation depends on the issuing and consuming sessions being the same. If a product page is cached with the token in it, it can become stale on a subsequent rendering if the session changes.\n\nTo check that you're safe, after having upgraded locally, go through the following steps:\n\n- Enable cache on dev mode:\n\n  ```bash\n  bin\u002Frails dev:cache\n  ```\n\n- Visit the page for a variant with stock.\n\n- Reload that page several times.\n\n- Click on the \"Add to cart\"  button.\n\n- Remember to rerun `bin\u002Frails dev:cache` to turn off cache again.\n\nNo error or session reset should happen.\n\nOtherwise, you can try with:\n\n- Revisiting how your session gets expired.\n- Changing the caching strategy to exclude the token.\n\n#### Using weaker CSRF protection strategies\n\nIt's also important to understand that a complete fix will only be in place when using the `:exception` forgery protection strategy. The `solidus_frontend` engine can't do pretty much anything otherwise. Using weaker CSRF strategies should be an informed and limited decision made by the application team. After the upgrade:\n\n- An app using `:null_session` should also be safe, but there will be side effects. That strategy runs with a null object session. As such, no order and no user is found on it. A new `cart` state order is created in the database, associated with no user. Next time the user visits the site, they won't find any difference in its cart state.\n\n- An app using `:reset_session` is not entirely safe. That strategy resets the session. That means that registered users will be logged out. Next time a user visits, they'll see the cart with the items added during the CSRF attack, although it won't be associated with their account in the case of registered users.\n\n#### Reversing the update\n\nIf you still want to deploy the upgraded version before changing your application code (if the latter is needed), you can add the following workaround to your `config\u002Fapplication.rb` (however, take into account that you'll keep being vulnerable):\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.skip_before_action :verify_authenticity_token, only: [:populate]\nend\n```\n\n### Workarounds\n\nIf an upgrade is not an option, you can work around the issue by adding the following to `config\u002Fapplication.rb`:\n\n```ruby\nconfig.after_initialize do\n  Spree::OrdersController.protect_from_forgery with: ApplicationController.forgery_protection_strategy.name.demodulize.underscore.to_sym, only: [:populate]\nend\n```\n\nHowever, go through the same safety check detailed on \"Upgrade notes\" above.\n\n### References\n\n- [CSRF on the Rails guides](https:\u002F\u002Fguides.rubyonrails.org\u002Fsecurity.html#cross-site-request-forgery-csrf)\n- [How CSRF tokens are generated and validated on Rails](https:\u002F\u002Fmedium.com\u002Frubyinside\u002Fa-deep-dive-into-csrf-protection-in-rails-19fa0a42c0ef)\n- [Solidus security](https:\u002F\u002Fsolidus.io\u002Fsecurity\u002F)\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an [issue](https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus\u002Fissues) or a [discussion](https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus\u002Fdiscussions) in Solidus.\n* Email us at [security@solidus.io](mailto:security@soliidus.io)\n* Contact the core team on [Slack](http:\u002F\u002Fslack.solidus.io\u002F)\n","2022-01-06T18:33:00Z",{"cvss_v3.1":37},{"scope":38,"version":39,"baseScore":40,"attackVector":41,"baseSeverity":42,"vectorString":43,"integrityImpact":44,"userInteraction":45,"attackComplexity":44,"availabilityImpact":45,"privilegesRequired":45,"confidentialityImpact":45},"UNCHANGED","3.1",5.3,"NETWORK","MEDIUM","CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:U\u002FC:N\u002FI:L\u002FA:N","LOW","NONE",true,[48],"CWE-352",[50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181],"cpe:2.3:a:nebulab:solidus:1.3.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.2.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.13:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.11:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.7.0:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.3.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:prerelease2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.0:rc3:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.3.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.3.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.1.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.2.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.6:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.4.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.9:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.0:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.6:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.4.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:prerelease3:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.3.0:rc2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.4.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.1.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.10:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.1.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:rc2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.0:prerelease2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.2.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.0:rc2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.7.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:*:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.4.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.7.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.2.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.4.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:prerelease:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.4.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.4.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.1.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.7:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.12:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.2.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.1.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.6.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.0:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.1.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.7.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.7:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.0:rc2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.0:rc2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.5:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.3:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.7.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.1.0:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.1.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.8:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.6:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.1.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.2:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.4.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.3.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.6:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.4.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.0:beta2:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.2.0:rc1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.4.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.0.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.11.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.5.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.1.0:beta1:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.1:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.10.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:3.0.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.9.4:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.3.0:-:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:2.8.6:*:*:*:*:*:*:*","cpe:2.3:a:nebulab:solidus:1.0.2:*:*:*:*:*:*:*","cpe:2.3:a:solidus_frontend:solidus_frontend:*:*:*:*:*:*:*:*",[183,184],"Nebulab Solidus","Solidus_Frontend Solidus Frontend",[186,187,188,189,190,191],"https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus\u002Fcommit\u002F4d17cacf066d9492fc04eb3a0b16084b47376d81","https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus\u002Fcommit\u002Fa1b9bf7f24f9b8684fc4d943eacb02b1926c77c6","https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus\u002Fsecurity\u002Fadvisories\u002FGHSA-h3fg-h5v3-vf8m","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2021-43846","https:\u002F\u002Fgithub.com\u002Frubysec\u002Fruby-advisory-db\u002Fblob\u002Fmaster\u002Fgems\u002Fsolidus_frontend\u002FCVE-2021-43846.yml","https:\u002F\u002Fgithub.com\u002Fsolidusio\u002Fsolidus",0.62,0.00594,0.48094,false,{"timestamp":6,"automatable":197,"tech_impact":198,"exploitation":199,"cisa_decision":200,"cisa_remediation_timeline":201},"no","partial","none",{},"FSU",[203],{"name":204,"source":205,"tactics":206,"technique_id":208},"Exploit Public-Facing Application","attack_vector",[207],"initial-access","T1190",[210],{"link":188},{"count":212,"next":213,"previous":6,"results":214},26,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&page_size=3&sorted_by=-published_at",[215,223,231],{"id":216,"title":217,"summary":218,"published_at":219,"type":220,"link":221,"image_url":222},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":224,"title":225,"summary":226,"published_at":227,"type":228,"link":229,"image_url":230},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":232,"title":233,"summary":234,"published_at":235,"type":236,"link":237,"image_url":238},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"]