Summary
Lemmy allows an authenticated low-privileged user to create a link post through POST /api/v3/post. When a post is created in a public community, the backend asynchronously sends a Webmention to the attacker-controlled link target.
The submitted URL is checked for syntax and scheme, but the audited code path does not reject loopback, private, or link-local destinations before the Webmention request is issued. This lets a normal user trigger server-side HTTP requests toward internal services.
Details
The entry point is the normal post creation API. The user-controlled url field is accepted, normalized with diesel_url_create(), and only validated with is_valid_url(). That validation allows http and https but does not implement internal address rejection.
The post creation flow then schedules Webmention delivery for public communities. This creates a direct source-to-sink path from an externally supplied post URL to a server-side outbound HTTP request.
Core vulnerable code path:
// crates/api_crud/src/post/create.rs
let url = diesel_url_create(data.url.as_deref())?;
if let Some(url) = &url {
is_url_blocked(url, &url_blocklist)?;
is_valid_url(url)?;
}
// crates/utils/src/utils/validation.rs
pub fn is_valid_url(url: &Url) -> LemmyResult<()> {
let is_valid = ["http", "https", "magnet"].contains(&url.scheme());
if !is_valid {
Err(LemmyErrorType::InvalidUrl)?
}
Ok(())
}
// crates/api_crud/src/post/create.rs
if community.visibility == CommunityVisibility::Public {
let post = inserted_post.clone();
let url = url.clone();
spawn_try_task(async move {
if let Some(url) = url {
Webmention::new(post.ap_id.clone().into(), url.into()).send().await?;
}
Ok(())
});
}
These snippets matter because they show that the attacker controls CreatePost.url, the only validation is scheme-level, and the resulting URL is later used for server-side Webmention delivery.
PoC
_Complete instructions, including specific configuration details, to reproduce the vulnerability._Prerequisites:
- The attacker has a valid low-privileged account.
- The attacker can post to a public community.
Practical reproduction flow:
- Run an HTTP listener on an internal or loopback-reachable address from the Lemmy server's perspective, such as
127.0.0.1:8081. - Authenticate as a normal user.
- Submit a post to a public community with
urlset to the internal target. - Observe the Lemmy API return a normal post creation response.
- Observe the internal HTTP listener receive a request from the Lemmy server shortly afterwards.
Complete PoC:
POST /api/v3/post HTTP/1.1
Host: victim.example
Authorization: Bearer <low-priv-jwt>
Content-Type: application/json
{
"name": "wm-ssrf",
"community_id": 1,
"url": "http://127.0.0.1:8081/",
"body": null,
"alt_text": null,
"honeypot": null,
"nsfw": false,
"language_id": null,
"custom_thumbnail": null
}
Outcome:
- The API returns a successful
post_viewresponse. - The Lemmy server later issues an outbound request toward
http://127.0.0.1:8081/as part of Webmention processing.
Impact
An authenticated user can use the application server as a blind SSRF primitive against internal HTTP services. This can expose internal network reachability, trigger internal webhooks or administrative endpoints, and expand the attack surface beyond the public deployment boundary.
Because the sink is reached after ordinary user content submission, the issue is practical to exploit in real deployments where normal users can post to public communities.
Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside. Typical impact: access to internal metadata services, internal APIs, or cloud credentials.
CVE-2026-42180 has a CVSS score of 6.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.19.18); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-42180? CVE-2026-42180 is a medium-severity server-side request forgery (SSRF) vulnerability in lemmy_api_common (rust), affecting versions < 0.19.18. It is fixed in 0.19.18. Untrusted input controls the target URL of a server-initiated request, which may reach internal services not otherwise accessible from outside.
- How severe is CVE-2026-42180? CVE-2026-42180 has a CVSS score of 6.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of lemmy_api_common are affected by CVE-2026-42180? lemmy_api_common (rust) versions < 0.19.18 is affected.
- Is there a fix for CVE-2026-42180? Yes. CVE-2026-42180 is fixed in 0.19.18. Upgrade to this version or later.
- Is CVE-2026-42180 exploitable, and should I be worried? Whether CVE-2026-42180 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-42180 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-42180? Upgrade
lemmy_api_commonto 0.19.18 or later.