Stoatchat
Monthly
MFA bypass in StoatChat before 0.15.5 allows an authenticated attacker to satisfy the MFA step-up re-authentication challenge for another user's session by presenting an MFA ticket minted from their own account, enabling them to disable the victim's TOTP, view recovery codes, and perform other sensitive account operations without knowing the victim's credentials. Exploitation is conditionally gated: the attacker must hold both a valid StoatChat account (to obtain a legitimate ticket) and an already-stolen victim session token, which the flaw itself does not provide. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released 0.15.5 as the fix.
MFA enforcement in Stoatchat before 0.15.5 can be bypassed by an attacker who already holds the victim's password, because the platform applies rate limiting only per source IP to TOTP challenges and allows a single MFA challenge ticket to be reused across repeated failed attempts. By rotating source addresses, an attacker can guess the TOTP code essentially without an account-level attempt limit and gain full account access; exploitation requires that MFA is enabled on the target account, and no public exploit code has been identified at time of analysis.
Unauthenticated remote attackers can use the January media proxy/embed service in stoatchat before 0.15.5 to probe the host filesystem and drain server resources. When January fetches an attacker-hosted resource served as image/svg+xml, the SVG <image href> values are resolved as local filesystem paths, so observable response-time differences reveal whether local files exist and supported local image files are disclosed after re-encoding, while unbounded reads of each referenced file generate large amounts of filesystem I/O and memory pressure (a published proof of concept drives roughly 4.34 GB of reads) causing denial of service. Publicly available exploit code exists, no authentication or user interaction is required, and the issue is fixed in version 0.15.5.
Authenticated members of a Stoat Chat deployment can permanently (until restart) disable push notifications and mention badges for the entire instance by sending five specially crafted role-mention messages. The messages are routed to the acknowledgement worker that handles mass mentions, and the resulting unhandled exception terminates every acknowledgement worker process-wide, so the failure is not confined to the sender's own session. The issue affects all stoatchat releases before 0.15.5; exploitation requires a valid account with the ability to post messages containing role mentions (PR:L), with no victim interaction needed. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released a fix in 0.15.5.
Missing authorization in stoatchat's Subscribe message handler exposes private server membership data to any authenticated user on the platform. By sending a crafted Subscribe message referencing an arbitrary server ID, an authenticated attacker receives a live stream of UserUpdate events - including display names, avatars, and presence status - for members of private servers they have no legitimate access to. No public exploit code has been identified at time of analysis, but the attack is trivially repeatable by any account holder, requiring only knowledge of a target server's ID.
Permission bypass in stoatchat before 0.15.0 allows authenticated users holding only ViewChannel access to read individual message content through the message_fetch route, circumventing the ReadMessageHistory restriction that bulk read routes correctly enforce. Organizations that deliberately deny ReadMessageHistory to specific users or roles - intending to block historical message access - are exposed because the single-message fetch path uses a weaker authorization check. No public exploit code has been identified and the product is not listed in CISA KEV, but the authorization inconsistency is straightforward to exploit for any actor already authenticated to the platform.
Memory exhaustion denial of service in stoatchat before 0.15.0 allows unauthenticated remote attackers to crash the service by submitting concurrent proxy requests referencing attacker-hosted SVGs with arbitrarily large viewBox width and height values. The proxy endpoint allocates memory proportional to declared SVG dimensions without enforcing any upper bound (CWE-400), and concurrent exploitation amplifies impact across all running replicas simultaneously. No public exploit code or CISA KEV listing has been identified at time of analysis; the CVSS 4.0 score of 8.7 reflects the high availability impact with no confidentiality or integrity component.
Server-side request forgery in Stoatchat before 0.14.0 lets unauthenticated, network-accessible attackers reach internal services that a DNS-based IP blocklist was meant to protect. The url_is_blacklisted function validates only the first resolved address, while the underlying HTTP client iterates over all cached DNS addresses, so a hostname resolving to both an allowed and an internal/blocked IP slips past the check. No public exploit identified at time of analysis; the issue is fixed in the v0.14.0 release and was reported by VulnCheck.
Server-side request forgery in stoatchat before 0.13.5 allows remote unauthenticated attackers to coerce the server into making arbitrary outbound requests through the /proxy and /embed endpoints, which accept attacker-supplied URLs without DNS resolution filtering or private-IP validation. Reported by VulnCheck and carrying a CVSS 4.0 score of 9.2, it lets attackers enumerate internal services, fingerprint applications, and reach cloud instance-metadata endpoints. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Stoatchat releases prior to 0.15.5 hand unauthenticated remote attackers an account-existence oracle: POST /api/auth/session/login returns error responses whose 'location' fields differ for registered versus unregistered email addresses, and those same fields leak internal source file paths. The root issue is a CWE-209 sensitive-information-in-error-message flaw that yields email enumeration and path disclosure rather than authentication bypass or data modification, and no public exploit code was identified at time of analysis. The vendor has released a fix, and the independent assessment treats the practical risk as a low-severity information-disclosure issue even though the vendor-published CVSS 4.0 score is 6.9.
Username validation bypass in stoatchat (Stoat) before 0.15.5 lets an authenticated user register or change a username that fails the intended character allowlist and 32-character length limit, because the sanitization/normalization step runs after validation instead of being re-checked. Exploitation requires a valid account and access to the account-creation or username-update flow (CVSS 4.0 vector shows PR:L, and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), so only the integrity of the username namespace is impacted - no confidentiality or availability loss and no privilege escalation. A vendor patch is available in 0.15.5, and no public exploit code or confirmed active exploitation was identified at time of analysis.
SSRF protection bypass in stoatchat before 0.15.0 exposes loopback-bound services to unauthenticated remote attackers through incomplete IPv6 address filtering on the /proxy and /embed endpoints. The application's blocklist omits the IPv6 unspecified address (::), which can resolve to or function as the loopback interface, enabling crafted requests using IPv6 literal URL syntax to reach internal services not intended to be externally accessible. No public exploit code or CISA KEV listing exists at time of analysis, but the zero-friction exploitation prerequisites make this a meaningful disclosure risk wherever sensitive services are loopback-bound on stoatchat hosts.
Internal file disclosure in Stoat for Android allows any process capable of local intent dispatch to exfiltrate the app's internal storage - including the local message database and cached authentication tokens - through an unvalidated URI passed to the exported ShareTargetActivity. The attacker triggers a single, deceptive share interaction in which the victim selects a destination channel while the Stoat composer conceals the true nature of the attachment, showing only 'attachment' with no filename. No public exploit code has been identified and this CVE is not listed in CISA KEV; the upstream fix is confirmed via commit 50d5f5143940809ebb5a61e5f507c956c33aa970, though a specific patched release version is not independently confirmed.
Webhook token disclosure in stoatchat (the Rust 'delta' backend of the Revolt/stoatchat platform) lets any channel member holding only ViewChannel (read) permission enumerate a channel's webhooks and read their secret tokens. Because a retrieved token authorizes posting, the attacker can then inject arbitrary messages while impersonating a bot or webhook, bypassing the channel's ManageWebhooks and posting permissions. Reported by VulnCheck and fixed in 20250210-1 (0.8.2); no public exploit identified at time of analysis.
Denial of service in stoatchat (delta) versions before 20250210-1 (0.8.2) lets a remote unauthenticated attacker exhaust server resources by abusing the 'nearby' message query route. A logic error passes a message limit of zero to the database, which MongoDB interprets as 'no limit', so a single crafted request downloads an entire channel's history; parallelized requests amplify this into resource-exhaustion DoS. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the upstream fix and a VulnCheck advisory are published.
MFA bypass in StoatChat before 0.15.5 allows an authenticated attacker to satisfy the MFA step-up re-authentication challenge for another user's session by presenting an MFA ticket minted from their own account, enabling them to disable the victim's TOTP, view recovery codes, and perform other sensitive account operations without knowing the victim's credentials. Exploitation is conditionally gated: the attacker must hold both a valid StoatChat account (to obtain a legitimate ticket) and an already-stolen victim session token, which the flaw itself does not provide. No public exploit code or confirmed active exploitation was identified at time of analysis, and the vendor has released 0.15.5 as the fix.
MFA enforcement in Stoatchat before 0.15.5 can be bypassed by an attacker who already holds the victim's password, because the platform applies rate limiting only per source IP to TOTP challenges and allows a single MFA challenge ticket to be reused across repeated failed attempts. By rotating source addresses, an attacker can guess the TOTP code essentially without an account-level attempt limit and gain full account access; exploitation requires that MFA is enabled on the target account, and no public exploit code has been identified at time of analysis.
Unauthenticated remote attackers can use the January media proxy/embed service in stoatchat before 0.15.5 to probe the host filesystem and drain server resources. When January fetches an attacker-hosted resource served as image/svg+xml, the SVG <image href> values are resolved as local filesystem paths, so observable response-time differences reveal whether local files exist and supported local image files are disclosed after re-encoding, while unbounded reads of each referenced file generate large amounts of filesystem I/O and memory pressure (a published proof of concept drives roughly 4.34 GB of reads) causing denial of service. Publicly available exploit code exists, no authentication or user interaction is required, and the issue is fixed in version 0.15.5.
Authenticated members of a Stoat Chat deployment can permanently (until restart) disable push notifications and mention badges for the entire instance by sending five specially crafted role-mention messages. The messages are routed to the acknowledgement worker that handles mass mentions, and the resulting unhandled exception terminates every acknowledgement worker process-wide, so the failure is not confined to the sender's own session. The issue affects all stoatchat releases before 0.15.5; exploitation requires a valid account with the ability to post messages containing role mentions (PR:L), with no victim interaction needed. No public exploit code and no confirmed active exploitation were identified at time of analysis, and the vendor has released a fix in 0.15.5.
Missing authorization in stoatchat's Subscribe message handler exposes private server membership data to any authenticated user on the platform. By sending a crafted Subscribe message referencing an arbitrary server ID, an authenticated attacker receives a live stream of UserUpdate events - including display names, avatars, and presence status - for members of private servers they have no legitimate access to. No public exploit code has been identified at time of analysis, but the attack is trivially repeatable by any account holder, requiring only knowledge of a target server's ID.
Permission bypass in stoatchat before 0.15.0 allows authenticated users holding only ViewChannel access to read individual message content through the message_fetch route, circumventing the ReadMessageHistory restriction that bulk read routes correctly enforce. Organizations that deliberately deny ReadMessageHistory to specific users or roles - intending to block historical message access - are exposed because the single-message fetch path uses a weaker authorization check. No public exploit code has been identified and the product is not listed in CISA KEV, but the authorization inconsistency is straightforward to exploit for any actor already authenticated to the platform.
Memory exhaustion denial of service in stoatchat before 0.15.0 allows unauthenticated remote attackers to crash the service by submitting concurrent proxy requests referencing attacker-hosted SVGs with arbitrarily large viewBox width and height values. The proxy endpoint allocates memory proportional to declared SVG dimensions without enforcing any upper bound (CWE-400), and concurrent exploitation amplifies impact across all running replicas simultaneously. No public exploit code or CISA KEV listing has been identified at time of analysis; the CVSS 4.0 score of 8.7 reflects the high availability impact with no confidentiality or integrity component.
Server-side request forgery in Stoatchat before 0.14.0 lets unauthenticated, network-accessible attackers reach internal services that a DNS-based IP blocklist was meant to protect. The url_is_blacklisted function validates only the first resolved address, while the underlying HTTP client iterates over all cached DNS addresses, so a hostname resolving to both an allowed and an internal/blocked IP slips past the check. No public exploit identified at time of analysis; the issue is fixed in the v0.14.0 release and was reported by VulnCheck.
Server-side request forgery in stoatchat before 0.13.5 allows remote unauthenticated attackers to coerce the server into making arbitrary outbound requests through the /proxy and /embed endpoints, which accept attacker-supplied URLs without DNS resolution filtering or private-IP validation. Reported by VulnCheck and carrying a CVSS 4.0 score of 9.2, it lets attackers enumerate internal services, fingerprint applications, and reach cloud instance-metadata endpoints. There is no public exploit identified at time of analysis and it is not listed in CISA KEV.
Stoatchat releases prior to 0.15.5 hand unauthenticated remote attackers an account-existence oracle: POST /api/auth/session/login returns error responses whose 'location' fields differ for registered versus unregistered email addresses, and those same fields leak internal source file paths. The root issue is a CWE-209 sensitive-information-in-error-message flaw that yields email enumeration and path disclosure rather than authentication bypass or data modification, and no public exploit code was identified at time of analysis. The vendor has released a fix, and the independent assessment treats the practical risk as a low-severity information-disclosure issue even though the vendor-published CVSS 4.0 score is 6.9.
Username validation bypass in stoatchat (Stoat) before 0.15.5 lets an authenticated user register or change a username that fails the intended character allowlist and 32-character length limit, because the sanitization/normalization step runs after validation instead of being re-checked. Exploitation requires a valid account and access to the account-creation or username-update flow (CVSS 4.0 vector shows PR:L, and our independent assessment scores it CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N), so only the integrity of the username namespace is impacted - no confidentiality or availability loss and no privilege escalation. A vendor patch is available in 0.15.5, and no public exploit code or confirmed active exploitation was identified at time of analysis.
SSRF protection bypass in stoatchat before 0.15.0 exposes loopback-bound services to unauthenticated remote attackers through incomplete IPv6 address filtering on the /proxy and /embed endpoints. The application's blocklist omits the IPv6 unspecified address (::), which can resolve to or function as the loopback interface, enabling crafted requests using IPv6 literal URL syntax to reach internal services not intended to be externally accessible. No public exploit code or CISA KEV listing exists at time of analysis, but the zero-friction exploitation prerequisites make this a meaningful disclosure risk wherever sensitive services are loopback-bound on stoatchat hosts.
Internal file disclosure in Stoat for Android allows any process capable of local intent dispatch to exfiltrate the app's internal storage - including the local message database and cached authentication tokens - through an unvalidated URI passed to the exported ShareTargetActivity. The attacker triggers a single, deceptive share interaction in which the victim selects a destination channel while the Stoat composer conceals the true nature of the attachment, showing only 'attachment' with no filename. No public exploit code has been identified and this CVE is not listed in CISA KEV; the upstream fix is confirmed via commit 50d5f5143940809ebb5a61e5f507c956c33aa970, though a specific patched release version is not independently confirmed.
Webhook token disclosure in stoatchat (the Rust 'delta' backend of the Revolt/stoatchat platform) lets any channel member holding only ViewChannel (read) permission enumerate a channel's webhooks and read their secret tokens. Because a retrieved token authorizes posting, the attacker can then inject arbitrary messages while impersonating a bot or webhook, bypassing the channel's ManageWebhooks and posting permissions. Reported by VulnCheck and fixed in 20250210-1 (0.8.2); no public exploit identified at time of analysis.
Denial of service in stoatchat (delta) versions before 20250210-1 (0.8.2) lets a remote unauthenticated attacker exhaust server resources by abusing the 'nearby' message query route. A logic error passes a message limit of zero to the database, which MongoDB interprets as 'no limit', so a single crafted request downloads an entire channel's history; parallelized requests amplify this into resource-exhaustion DoS. No public exploit identified at time of analysis and the flaw is not in CISA KEV, but the upstream fix and a VulnCheck advisory are published.