ghsa

## Fickling Assessment Based on the test case provided in the original report below, this bypass was caused by `pty` missing from our block list of unsafe module imports (as previously documented in #108), rather than the unused variable heuristic. This led to unsafe pickles based on `pty.spawn()` being incorrectly flagged as `LIKELY_SAFE`, and was fixed in https://github.com/trailofbits/fickling/pull/187. ## Original report ### Summary An unsafe deserialization vulnerability in Fickling allows a crafted pickle file to bypass the "unused variable" heuristic, enabling arbitrary code execution. This bypass is achieved by adding a trivial operation to the pickle file that "uses" the otherwise unused variable left on the stack after a malicious operation, tricking the detection mechanism into classifying the file as safe. ### Details Fickling relies on the heuristic of detecting unused variables in the VM's stack after execution. Opcodes like `REDUCE`, `OBJ`, and `INST`, which can be ...

## Fickling Assessment Based on the test case provided in the original report below, this bypass was caused by `marshal` and `types` missing from the block list of unsafe module imports, Fickling started blocking both modules to address this issue. This was fixed in https://github.com/trailofbits/fickling/pull/186. The crash is unrelated and has no security impact—it will be addressed separately. ## Original report ### Summary There's missing detection for the python modules, `marshal.loads` and `types.FunctionType` and Fickling throws unhandled ValueErrors when the stack is deliberately exhausted. ### Details Fickling simply doesn't have the aforementioned modules in its list of unsafe imports and therefore it fails to get detected. ### PoC The following is a disassembled view of a malicious pickle file that uses these modules: ``` 0: \x80 PROTO 4 2: \x95 FRAME 0 11: \x8c SHORT_BINUNICODE 'marshal' 20: \x8c SHORT_BINUNICODE 'loads' 27: \x93 STACK_GLOBAL...

### Summary The `io.netty.handler.codec.http.HttpRequestEncoder` CRLF injection with the request uri when constructing a request. This leads to request smuggling when `HttpRequestEncoder` is used without proper sanitization of the uri. ### Details The `HttpRequestEncoder` simply UTF8 encodes the `uri` without sanitization (`buf.writeByte(SP).writeCharSequence(uriCharSequence, CharsetUtil.UTF_8);`) The default implementation of HTTP headers guards against such possibility already with a validator making it impossible with headers. ### PoC Simple reproducer: ```java public static void main(String[] args) { EmbeddedChannel client = new EmbeddedChannel(); client.pipeline().addLast(new HttpClientCodec()); EmbeddedChannel server = new EmbeddedChannel(); server.pipeline().addLast(new HttpServerCodec()); server.pipeline().addLast(new ChannelInboundHandlerAdapter() { @Override public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception { Syst...

### Impact It was possible to retrieve user notification settings or list all users via API. ### Patches * https://github.com/WeblateOrg/weblate/pull/17256 ### References Thanks to Hector Ruiz Ruiz & NaxusAI for responsibly disclosing this vulnerability to Weblate.

### Impact It was possible to trigger repository updates for many repositories via a crafted webhook payload. ### Patches * https://github.com/WeblateOrg/weblate/pull/17221 ### Workarounds Disabling webhooks completely using ENABLE_HOOKS avoids this vulnerability. ### References Thanks to Hector Ruiz Ruiz & NaxusAI for responsibly disclosing this vulnerability to us.

LikeC4 uses React and Next.js: which contain known RCE vulnerabilities, as seen in CVE-2025-55182. [2025-12-15] Edit: the last fixes published by React were not thorough, a new set of fix releases completes the mitigation; see https://react.dev/blog/2025/12/11/denial-of-service-and-source-code-exposure-in-react-server-components

### Summary When using an untrusted reverse proxy or not using a reverse proxy at all, attackers can bypass IP rate limiting by adding a forged X-Forwarded-For header. Starting with version 2025.9.1, an option (`trustProxy`) has been added in config file to prevent this from happening. However, it is initialized with an insecure default value before version 2025.12.0, making it still vulnerable if the configuration is not set correctly. ### Workaround If you are running Misskey with a trusted reverse proxy, you should *not* be affected by this vulnerability. - There is no workaround for the Misskey itself. Please update Misskey to the latest version or set up a trusted reverse proxy. - From v2025.9.1 to v2025.11.1, workaround is available. Set `trustProxy: false` in config file. - This is patched in v2025.12.0 by flipping default value of `trustProxy` to `false`. If you are using trusted reverse proxy and not remember you manually overrided this value, please take time to check your...

### Summary After adding private posts (followers, direct) that you do not have permission to view to your favorites or clips, you can export them to view the contents of the private posts. ### PoC 1. Create an account (X) for testing and an account (Y) for private posts on the same server. 2. Send appropriate content from Y using "Follow" 3. Send appropriate content to any user using "Nominate" from Y 4. Obtain the URLs for the two posts above using Y's account. 5. Query the URLs for the two posts using X and add them to your favorites or clips. 6. Export your favorites or clips using X. 7. Check the exported data. Note: Verified in v2025.11.1 ### Impact This could allow an attacker to view the contents of private posts. If you have pinned private posts, this could be a real problem, as the ID of the private post can be obtained by viewing the user page on the original server.

### Impact It was possible to accept an invitation opened by a different Weblate user. ### Patches * https://github.com/WeblateOrg/weblate/pull/16913 ### Workarounds Users should avoid leaving Weblate sessions with an unattended opened invitation. ### References Thanks to Nahid0x for responsibly disclosing this vulnerability to Weblate.

A flaw was found in runtimes-inventory-rhel8-operator. An internal proxy component is incorrectly configured. Because of this flaw, the proxy attaches the cluster's main administrative credentials to any command it receives, instead of only the specific reports it is supposed to handle. This allows a standard user within the cluster to send unauthorized commands to the management platform, effectively acting with the full permissions of the cluster administrator. This could lead to unauthorized changes to the cluster's configuration or status on the Red Hat platform.