CVE-2026-71366 is a server-side request forgery (SSRF) vulnerability affecting multiple notification backends in Red Hat Ansible Automation Platform 2.5 for RHEL 8. The affected backends (webhook, Mattermost, Rocket.Chat, and Grafana) do not validate notification template URLs against private, loopback, or reserved IP ranges, allowing an organization notification administrator to cause the AWX control node to send HTTP requests to internal or loopback addresses. The webhook backend also follows HTTP redirects and resends Basic Authentication credentials to redirected hosts without validation, risking credential exfiltration. The Grafana backend exposes its API key to the configured target URL. Red Hat has rated this vulnerability as having an Important impact and has released a security update to fix it.
Rocket.Chat versions prior to 8.8.0, 8.7.1, 8.6.2, 8.5.3, 8.4.6, 8.3.8, 8.2.8, 8.1.8, and 7.10.15 have a vulnerability in the Meteor DDP methods getThreadsList and getThreadMessages. These methods accept raw parameters without schema validation, allowing a MongoDB operator object to be used instead of a string room or message ID. This flaw causes private thread parents and their full reply content to be disclosed to any low-privilege authenticated user. The REST route equivalent was patched in version 5.0, but the DDP method remains vulnerable. The CVSS score is 4.3, indicating medium severity.
Lightdash stores the webhook URL supplied with a scheduled delivery and later posts to it from sendWebhook in packages/backend/src/clients/GoogleChat/GoogleChatClient.ts and in packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts. In affected versions both call fetch on the stored URL directly. The validatePublicHttpUrl helper in packages/backend/src/utils/ssrfProtection.ts, used for MCP server URLs, is not applied on either path, and the webhook fields carry no server-side URL constraint. A user able to create or trigger a scheduled delivery can therefore direct the server to issue POST requests to private, loopback and link-local addresses, including cloud metadata endpoints, and can distinguish reachable internal services from unreachable ones through the resulting errors. The upstream response is never returned to the requester; on a failure status its body is written to the server log instead. Version 1.146.4 routes both clients through postSchedulerWebhook from packages/backend/src/utils/schedulerWebhookValidation rather than calling fetch directly.
stoatchat versions before 0.15.0 have a missing authorization vulnerability in the Subscribe message handler. This flaw allows authenticated attackers to subscribe to member-update topics of private servers without being members. As a result, attackers can enumerate members and monitor profile updates such as display names, avatars, and status changes that they should not have access to.
In May 2026, a cyber-espionage campaign by the Armored Likho group (also known as Eagle Werewolf) targeted private individuals and organizations across Russia, including major corporations, public sector entities, IT companies, and educational institutions. The attackers employed fake donation service applications as initial infection vectors. The campaign introduced the Still Toolkit, comprising two Rust-based components: Still Sync, which steals Telegram session data and leverages the Telegram API to extract chat logs and media files, and Still Audio, an implant that conducts covert audio surveillance by detecting speech patterns and recording conversations. The toolkit demonstrates sophisticated capabilities including Dead Drop Resolver techniques, RMS-based voice activity detection, and gRPC-based C2 communications. The campaign shows significant code overlap with previous Armored Likho operations, particularly from February 2026, including identical dropper architecture, encryption algorithms, and inf...
Flowise before 3.1.4 fails to validate chatflow visibility in the unauthenticated text-to-speech endpoint, allowing attackers to abuse private chatflow TTS credentials. Unauthenticated attackers can generate unlimited text-to-speech audio using stored OpenAI or ElevenLabs API keys by providing a valid chatflow UUID, incurring costs on the chatflow owner's account.
TypeBot is a chatbot builder tool. Versions prior to 3.17.0 expose a deprecated public upload endpoint at `GET /api/v1/typebots/{typebotId}/blocks/{blockId}/storage/upload-url` that accepts an attacker-controlled `filePath` and returns a presigned S3 `PUT` URL for that exact key. Because the endpoint only checks that the referenced typebot is public and that the referenced block is a file input block, an unauthenticated attacker who knows a valid public `typebotId` and `blockId` can request presigned upload URLs for arbitrary objects in the shared bucket, including `private/...` and other tenants' `public/...` paths. Version 3.17.0 fixes this issue.
TypeBot is a chatbot builder tool. Prior to version 3.17.0, Typebot's WhatsApp status forwarding feature stores a workspace-configured webhook forwarding URL and later POSTs WhatsApp marketing/error status events to it from the server. The stored URL is only validated as a generic URL in settings, but the forwarding code uses the raw `ky` instance instead of the repository's SSRF-protected `safeKy` client. A workspace user who can configure WhatsApp settings can therefore make the Typebot server issue HTTP requests to internal services, private-network hosts, localhost, or metadata-style endpoints whenever the public WhatsApp production webhook receives a status payload that should be forwarded. Version 3.17.0 patches the issue.
Flowise versions 2.2.4 through 3.1.4 contain a missing authorization vulnerability in the POST /api/v1/openai-assistants-file/download endpoint that allows unauthenticated attackers to access private files by exploiting the endpoint's inclusion in the global authentication whitelist, which bypasses all session and API key verification. Attackers can supply valid chatflowId, chatId, and fileName identifiers to retrieve files from any chatflow on the instance, including private chatflows belonging to other workspaces or organizations.
### Summary
OnionShare CLI/Desktop 2.6.3 can follow symbolic links inside a selected Share or Website directory and serve the symlink target rather than limiting access to files physically contained in the selected directory. If a user shares a directory that contains attacker-supplied or otherwise untrusted symlinks, a remote recipient with access to the OnionShare service can read arbitrary local files readable by the OnionShare process that the symlink points to.
This affects the shipped `onionshare-cli` Python package and the desktop application because both call the same `onionshare_cli.web` file-indexing and streaming code.
### Details
Tested repository: `https://github.com/onionshare/onionshare` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`.
Affected product evidence:
- `cli/pyproject.toml` declares `onionshare_cli` version `2.6.3`.
- `desktop/pyproject.toml` declares `onionshare` version `2.6.3` and depends on `onionshare_cli` from `../cli`.
- `cli/setup.py` publishes `onionshare-cli` and includes `onionshare_cli.web` plus templates/static resources.
- `desktop/setup.py` publishes `onionshare` and exposes both `onionshare` and `onionshare-cli` console scripts.
Reachable default/common paths:
- CLI share mode is the default mode when no `--receive`, `--website`, or `--chat` flag is provided (`cli/onionshare_cli/__init__.py:234-241`) and accepts filesystem paths from CLI arguments (`cli/onionshare_cli/__init__.py:184-189`).
- CLI website mode is exposed through `--website` (`cli/onionshare_cli/__init__.py:55-59`).
- Desktop Website mode calls `self.web.website_mode.set_file_info(self.filenames)` before starting (`desktop/onionshare/tab/mode/website_mode/__init__.py:281-287`). Desktop Share mode calls `self.mode.web.share_mode.set_file_info(...)` before serving (`desktop/onionshare/tab/mode/share_mode/threads.py:42-49`).
- Documentation describes Website mode as selecting files/folders and serving them over OnionShare (`docs/source/features.rst:109-115`).
Root cause:
- `SendBaseModeWeb.set_file_info()` expands a single selected directory into immediate children and records `os.path.isfile()` entries without rejecting symlinks (`cli/onionshare_cli/web/send_base_mode.py:73-80`, `cli/onionshare_cli/web/send_base_mode.py:100-130`). On POSIX, `os.path.isfile()` follows a symlink to a regular file.
- Website mode serves any mapped file path through `stream_individual_file()` (`cli/onionshare_cli/web/website_mode.py:71-97`). `stream_individual_file()` opens the mapped filesystem path directly (`cli/onionshare_cli/web/send_base_mode.py:199-313`, especially `open(file_to_download, "rb")` at line 237).
- Share mode default `/download` can include a symlink target when a single selected folder is expanded into root entries and `ZipWriter.add_file()` calls `self.z.write(filename, ...)` without rejecting symlinks (`cli/onionshare_cli/web/share_mode.py:473-539`, `cli/onionshare_cli/web/share_mode.py:574-580`).
- Share mode with `--no-autostop-sharing` enables individual file downloads (`cli/onionshare_cli/web/share_mode.py:122-125`) and reaches the same direct streaming sink (`cli/onionshare_cli/web/share_mode.py:430-447`).
- A partial mitigation exists only for recursive ZIP directory traversal: `ZipWriter.add_dir()` skips `os.path.islink(full_filename)` (`cli/onionshare_cli/web/share_mode.py:582-600`). That mitigation does not cover Website mode, Share individual downloads, or Share ZIP generation for root-level symlinks after the single-folder expansion path.
False-positive screening performed:
- URL path traversal without a mapped entry returned 404; the issue is not raw `../` traversal but symlink following after a selected directory has been indexed.
- Jinja/template escaping and CSP do not mitigate this because the sink is file read/streaming.
- Share mode has a symlink skip in recursive ZIP addition, but local PoC confirmed sibling paths still dereference symlinks.
- The default non-public onion service requires the recipient to know the onion address and private key unless the user opts into public mode; this limits exposure but does not prevent disclosure to an authorized recipient or to anyone with the URL/key.
Affected versions / patched versions:
- Affected versions: unknown; confirmed in version `2.6.3` at commit `8cc75e1d7e88bd31f7276733449d412bf71c8999`. Earlier versions were not tested during this audit.
- Patched versions: 2.6.4
Severity:
- Rationale: `AV:N` because the file is exposed over the OnionShare HTTP service; `AC:H` because exploitation requires the victim to share a directory containing an attacker-influenced or untrusted symlink to a sensitive local file; `PR:L` because the attacker generally needs the OnionShare URL/private key unless the user intentionally runs public mode; `UI:R` because the OnionShare user must select/start sharing the affected directory; `S:U` because the same local process reads and serves the file; `C:H` because the symlink can point at high-value
Let's Chat 0.3.0 through 0.4.8 contains an improper authorization vulnerability that allows any authenticated user to archive any room on the server by sending a DELETE request to the rooms handler without ownership verification. Attackers can enumerate room IDs via the rooms listing endpoint and permanently archive private or password-protected rooms they cannot access, with no application-level recovery path requiring direct database intervention to restore.
Let's Chat 0.3.0 through 0.4.8 contains a broken access control vulnerability that allows authenticated attackers to download file attachments from private and password-protected rooms they are not a member of by exploiting missing room membership checks in the file retrieval route. Attackers can enumerate adjacent MongoDB ObjectIds derived from a known file ID to recover files uploaded by other users, as the GET /files/:id/:name route in app/controllers/files.js only enforces login authentication without consulting room membership or the Room.canJoin check.
The Better Messages – Chat Rooms, Group Chat, Private Messages & AI Chat Bots plugin for WordPress is vulnerable to arbitrary file deletion due to insufficient file path validation in the delete_sticker function in all versions up to, and including, 2.15.19. This makes it possible for authenticated attackers, with administrator-level access and above, to delete arbitrary files on the server, which can easily lead to remote code execution when the right file is deleted (such as wp-config.php). The prefix check intended to restrict deletion to the uploads directory can be bypassed by crafting a URL that begins with the legitimate uploads base URL but embeds ../ traversal sequences in the path portion, as the normalize_sticker function only applies esc_url_raw(), which does not strip ../ sequences, allowing the traversal payload to be stored verbatim in WordPress options.
The Adobe Acrobat extension for Chrome could be used to access conversations and data rendered in WhatsApp Web without any form of authentication. [...]
LMDeploy through 0.14.0, fixed in commit 03c3130, contains a server-side request forgery (SSRF) vulnerability in the _load_http_url function within the connection.py media handler, where the private-IP guard validates only the original URL without re-validating hosts after HTTP redirects. An unauthenticated attacker can submit a crafted image_url to the chat completions endpoint pointing to an attacker-controlled host that returns a redirect to a private IP or cloud-metadata endpoint, causing the server to follow the redirect and expose internal service content through the model pipeline.
text-generation-inference through 3.3.7 contains a server-side request forgery (SSRF) vulnerability in the OpenAI-compatible multimodal chat completions endpoint that allows unauthenticated network attackers to coerce the server into issuing arbitrary HTTP GET requests by supplying a crafted image_url value in chat message content. The fetch_image function in router/src/validation.rs performs no validation of private, loopback, link-local, or cloud metadata target addresses, and the reqwest HTTP client follows redirects by default, enabling attackers to bypass scheme checks via redirect chains to reach internal services and cloud instance-metadata endpoints for internal port scanning and credential theft.
The AI Engine WordPress plugin before 3.5.5 does not verify that a user owns the chatbot conversation referenced by a client-supplied identifier, allowing users with subscriber-level access to read other users' private conversations and take over their conversation records when the discussions feature is enabled.
FastGPT is a knowledge-based AI application platform. From 4.14.17 until 4.15.0-beta5, an authenticated FastGPT user can save a workflow node that points to another user's private HTTP toolset by using a crafted saved tool id such as http-<victim_toolset_app_id>/<tool_name>. The normal toolset routes deny access, but the workflow save and runtime path did not apply the same authorization check to the referenced toolset, allowing /api/v2/chat/completions to resolve the saved reference and execute the victim-owned HTTP tool. This issue is fixed in version 4.15.0-beta5.
