ghsa

### Summary A Server-Side Request Forgery (SSRF) vulnerability in Cowrie's emulated shell mode allows unauthenticated attackers to abuse the honeypot as an amplification vector for HTTP-based denial-of-service attacks against arbitrary third-party hosts. ### Details When Cowrie operates in emulated shell mode (the default configuration), it basically emulates common Linux commands. The `wget` and `curl` command emulations actually perform real outbound HTTP requests to the destinations specified by the attacker, as this functionality is intended to allow Cowrie to save downloaded files for later inspection. An attacker who connects to the honeypot via SSH or Telnet can repeatedly invoke these commands targeting a victim host. Since there was no rate limiting mechanism in place, the attacker could generate unlimited outbound HTTP traffic toward the victim. The requests originate from the honeypot's IP address, effectively masking the attacker's identity and turning the honeypot into...

**Vulnerability Overview** If an arbitrary path is specified in the request body's `fs_path`, the server serializes the Flow object into JSON and creates/overwrites a file at that path. There is no path restriction, normalization, or allowed directory enforcement, so absolute paths (e.g., /etc/poc.txt) are interpreted as is. **Vulnerable Code** 1. It receives the request body (flow), updates the DB, and then passes it to the file-writing sink. https://github.com/langflow-ai/langflow/blob/ac6e2d2eabeee28085f2739d79f7ce4205ca082c/src/backend/base/langflow/api/v1/flows.py#L154-L168 ```python @router.post("/", response_model=FlowRead, status_code=201) async def create_flow( *, session: DbSession, flow: FlowCreate, current_user: CurrentActiveUser, ): try: db_flow = await _new_flow(session=session, flow=flow, user_id=current_user.id) await session.commit() await session.refresh(db_flo...

**Vulnerability Overview** Langflow provides an API Request component that can issue arbitrary HTTP requests within a flow. This component takes a user-supplied URL, performs only normalization and basic format checks, and then sends the request using a server-side httpx client. It does not block private IP ranges (127.0.0.1, the 10/172/192 ranges) or cloud metadata endpoints (169.254.169.254), and it returns the response body as the result. Because the flow execution endpoints (/api/v1/run, /api/v1/run/advanced) can be invoked with just an API key, if an attacker can control the API Request URL in a flow, non-blind SSRF is possible—accessing internal resources from the server’s network context. This enables requests to, and collection of responses from, internal administrative endpoints, metadata services, and internal databases/services, leading to information disclosure and providing a foothold for further attacks. **Vulnerable Code** 1. When a flow runs, the API Request URL i...

### Impact Users importing contacts from untrusted sources. Specifically crafted contact data can lead to some of DOM modifications for the link button next to the field e.g. the link address can be overriden. CSS can be manipulated to give the button arbitrary look and change it's size so that any click on the screen would lead to the specified URL. Modifying event listeners does *not* seem to be possible so no JS can be executed (which would also be prevented by CSP). ## Technical details The data is included as part of the [mithril's hyperscript selector](https://mithril.js.org/hyperscript.html#css-selectors). It is possible to define a value like `][href=https://ddg.gg][style=position:fixed;width:150vw;height:200vh` which will be included in the selector passed to Mithril and will be interpreted as part of the code. ### Patches https://github.com/tutao/tutanota/commit/e28345f5f78f628f9d5c04e785f79543f01dca8b ### Workarounds Do not open contact viewer on unpatched versions. If t...

A flaw was found in the Keycloak LDAP User Federation provider. This vulnerability allows an authenticated realm administrator to trigger deserialization of untrusted Java objects via a malicious LDAP server configuration. ### Mitigation Disable LDAP referrals in all LDAP user providers in all realms if projects cannot upgrade to the patched versions.

**Description** The OAuth login state tokens are completely stateless and carry no per-request entropy or any data that could link them to the session that initiated the OAuth flow. `generate_state_token()` is always called with an empty `state_data` dict, so the resulting JWT only contains the fixed audience claim plus an expiration timestamp. \[1\] ```py state_data: dict[str, str] = {} state = generate_state_token(state_data, state_secret) authorization_url = await oauth_client.get_authorization_url( authorize_redirect_url, state, scopes, ) ``` *fastapi\_users/router/oauth.py:65-71* On callback, the library merely checks that the JWT verifies under `state_secret` and is unexpired; there is no attempt to match the state value to the browser that initiated the OAuth request, no correlation cookie, and no server-side cache. \[2\] ```py try: decode_jwt(state, state_secret, [STATE_TOKEN_AUDIENCE])...

### Impact On HTML elements handled by Orejime, one could run malicious code by embedding `javascript:` code within data attributes. When consenting to the related purpose, Orejime would turn data attributes into unprefixed ones (i.e. `data-href` into `href`), thus executing the code. This shouldn't have any impact on most setups, as elements handled by Orejime are generally hardcoded. The problem would only arise if somebody could inject HTML code within pages. See https://github.com/boscop-fr/orejime/issues/142 for the original report. ### Patches The problem has been patched by https://github.com/boscop-fr/orejime/pull/143. It is available in version 2.3.2. ### Workarounds The problem can be fixed outside of Orejime by sanitizing attributes which could contain executable code.

Multiple API endpoints allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only.

An API endpoint allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only.

Apache NiFi 1.20.0 through 2.6.0 include the GetAsanaObject Processor, which requires integration with a configurable Distribute Map Cache Client Service for storing and retrieving state information. The GetAsanaObject Processor used generic Java Object serialization and deserialization without filtering. Unfiltered Java object deserialization does not provide protection against crafted state information stored in the cache server configured for GetAsanaObject. Exploitation requires an Apache NiFi system running with the GetAsanaObject Processor, and direct access to the configured cache server. Upgrading to Apache NiFi 2.7.0 is the recommended mitigation, which replaces Java Object serialization with JSON serialization. Removing the GetAsanaObject Processor located in the nifi-asana-processors-nar bundle also prevents exploitation.