ghsa

### Impact A cryptographic semantic binding flaw in ALTCHA libraries allows challenge payload splicing, which may enable replay attacks. The HMAC signature does not unambiguously bind challenge parameters to the nonce, allowing an attacker to reinterpret a valid proof-of-work submission with a modified expiration value. This may allow previously solved challenges to be reused beyond their intended lifetime, depending on server-side replay handling and deployment assumptions. The vulnerability primarily impacts abuse-prevention mechanisms such as rate limiting and bot mitigation. It does not directly affect data confidentiality or integrity. ### Patches This issue has been addressed by enforcing explicit semantic separation between challenge parameters and the nonce during HMAC computation. Users are advised to upgrade to patched versions. ### Workarounds As a mitigation, implementations may append a delimiter to the end of the `salt` value prior to HMAC computation (for example...

## 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.