#auth

Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Airflow Common SQL Provider. When using the partition clause in SQLTableCheckOperator as parameter (which was a recommended pattern), Authenticated UI User could inject arbitrary SQL command when triggering DAG exposing partition_clause to the user. This allowed the DAG Triggering user to escalate privileges to execute those arbitrary commands which they normally would not have. This issue affects Apache Airflow Common SQL Provider: before 1.24.1. Users are recommended to upgrade to version 1.24.1, which fixes the issue.

When a `Some(...)` value was passed to the `properties` argument of either of these functions, a use-after-free would result. In practice this would nearly always result in OpenSSL treating the properties as an empty string (due to `CString::drop`'s behavior). The maintainers thank [quitbug](https://github.com/quitbug/) for reporting this vulnerability to us.

### Summary A Remote Code Execution (RCE) vulnerability caused by insecure deserialization has been identified in the latest version(v1.4.2) of BentoML. It allows any unauthenticated user to execute arbitrary code on the server. ### Details It exists an unsafe code segment in `serde.py`: ```Python def deserialize_value(self, payload: Payload) -> t.Any: if "buffer-lengths" not in payload.metadata: return pickle.loads(b"".join(payload.data)) ``` Through data flow analysis, it is confirmed that the `payload `content is sourced from an HTTP request, which can be fully manipulated by the attack. Due to the lack of validation in the code, maliciously crafted serialized data can execute harmful actions during deserialization. ### PoC Environment: - Server host: - IP: 10.98.36.123 - OS: Ubuntu - Attack host: - IP: 10.98.36.121 - OS: Ubuntu 1. Follow the instructions on the BentoML official README(https://github.com/bentoml/BentoML) to set up the environment. 1.1 I...

### Impact This is a high priority vulnerability and users must upgrade ASAP. The signature component of the authorization may be invalid, which would mean that as a client you can use any arbitrary secret to upload objects given the user already has prior WRITE permissions on the bucket, Prior knowledge of access-key, and bucket name this user might have access to - and an access-key with a WRITE permissions is necessary. However with relevant information in place, uploading random objects to buckets is trivial and easy via `curl` ### Patches Yes https://github.com/minio/minio/pull/21103 ### Workarounds Reject requests with `x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER` for now at LB layer, ask application users to use `STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER`

### Impact If the JIRA macro is installed, any logged in XWiki user could edit his/her user profile wiki page and use that JIRA macro, specifying a fake JIRA URL that returns an XML specifying a DOCTYPE pointing to a local file on the XWiki server host and displaying that file's content in one of the returned JIRA fields (such as the summary or description for example). For example: ``` <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <rss version="0.92"> ... <item> <title>&xxe;</title> <link>https://jira.xwiki.org/browse/XE-307</link> <project id="10222" key="XE">{RETIRED} XWiki Enterprise</project> <description>&xxe;</description> <environment/> ... ``` ### Patches The vulnerability has been patched in the JIRA Extension v8.6.5. ### Workarounds No easy workaround except to upgrade (which is easy using the XWiki Extension Manager). ### References * https://github.com/xwiki-contrib/jira/commit/98a...

### Summary The contents of arbitrary files can be returned to the browser. ### Impact Only apps explicitly exposing the Vite dev server to the network (using --host or [server.host config option](https://vitejs.dev/config/server-options.html#server-host)) are affected.. ### Details #### `.svg` Requests ending with `.svg` are loaded at this line. https://github.com/vitejs/vite/blob/037f801075ec35bb6e52145d659f71a23813c48f/packages/vite/src/node/plugins/asset.ts#L285-L290 By adding `?.svg` with `?.wasm?init` or with `sec-fetch-dest: script` header, the restriction was able to bypass. This bypass is only possible if the file is smaller than [`build.assetsInlineLimit`](https://vite.dev/config/build-options.html#build-assetsinlinelimit) (default: 4kB) and when using Vite 6.0+. #### relative paths The check was applied before the id normalization. This allowed requests to bypass with relative paths (e.g. `../../`). ### PoC ```bash npm create vite@latest cd vite-project/ npm insta...

### Original message: I found an issue with security grants on on properties in the GraphQL ItemNormalizer: If you use something like `#[ApiProperty(security: 'is_granted("PROPERTY_READ", [object, property])')]` on a member of an entity, the grant gets cached and is only evaluated once, even if the `object` in question is a different one. There is the `ApiPlatform\GraphQl\Serializer\ItemNormalizer::isCacheKeySafe()` method that seems to be intended to prevent this: https://github.com/api-platform/core/blob/88f5ac50d20d6510686a7552310cc567fcca45bf/src/GraphQl/Serializer/ItemNormalizer.php#L160-L164 and in its usage on line 90 it does indeed not create a cache key, but the `parent::normalize()` that is called afterwards still creates the cache key and causes the issue. ### Impact It grants access to properties that it should not. ### Workarounds Override the ItemNormalizer. Patched at: https://github.com/api-platform/core/commit/7af65aad13037d7649348ee3dcd88e084ef771f8

### Summary CWE-470 (Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') when having Javers selected as Entity Audit Framework ### Details In the following two occurences, user input directly leads to class loading without checking against e.g. a whitelist of allowed classes. This is also known as CWE-470 https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L88 https://github.com/jhipster/generator-jhipster-entity-audit/blob/e21e83135d10c77d92203c89cb0b0063914e8fe0/generators/spring-boot-javers/templates/src/main/java/_package_/web/rest/JaversEntityAuditResource.java.ejs#L124 So, if an attacker manages to place some malicious classes into the classpath and also has access to these REST interface for calling the mentioned REST endpoints, using these lines of code can lead to unintended remote cod...

Versions of the package expand-object from 0.0.0 to 0.4.2 are vulnerable to Prototype Pollution in the expand() function in index.js. This function expands the given string into an object and allows a nested property to be set without checking the provided keys for sensitive properties like __proto__.

Versions of the package spatie/browsershot from 0.0.0 to 5.0.3 are vulnerable to Server-side Request Forgery (SSRF) in the setUrl() function due to a missing restriction on user input, enabling attackers to access localhost and list all of its directories.