CVE-2026-107460: Apache Fesod (Incubating): UrlImageConverter SSRF protection bypass via DNS rebinding
Server-Side Request Forgery (SSRF) protection in the UrlImageConverter component of Apache Fesod (Incubating) fesod-sheet 2.0.2-incubating can be bypassed through DNS rebinding. When an application accepts an attacker-controlled image URL for spreadsheet writing, the converter checks the hostname's resolved IP addresses and then opens a separate connection that can resolve the hostname again. An attacker who controls DNS responses for the URL hostname may cause the connection to reach a restricted address after validation. CVE-2026-49328 covers SSRF in releases before 2.0.2-incubating; this issue is a DNS rebinding bypass of the protection in 2.0.2-incubating. Apache Fesod (Incubating) 2.1.0-incubating addresses the reported default-fetch scenario by disabling remote URL image fetching by default and requiring an explicit exact-host allowlist when the feature is enabled. Users should upgrade to 2.1.0-incubating. Applications enabling remote URL image fetching should allowlist only hostnames whose DNS and HTTP services are trusted.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Apache Fesod (Incubating) fesod-sheetto a version that resolves this vulnerability.Fixed in 2.1.0-incubating - Configuration
Keep remote URL image fetching disabled by default. If enabled, configure an explicit exact-host allowlist containing only hostnames whose DNS and HTTP services are trusted.
Apache Fesod (Incubating) UrlImageConverter remote URL image fetching = disabled by default; exact-host allowlist when enabled
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Applications using fesod-sheet 2.0.2-incubating are exposed when they accept attacker-controlled image URLs for spreadsheet writing and use UrlImageConverter to fetch them. The issue concerns the remote URL image-fetching path.
What does an attacker need to exploit this issue?
The attacker needs to supply an image URL using a hostname whose DNS responses they control. They can cause the hostname to resolve to an acceptable address during validation and to a restricted address when the converter opens its separate connection.
Is remote image fetching enabled by default after upgrading?
In 2.1.0-incubating, remote URL image fetching is disabled by default for the reported default-fetch scenario. Enabling it requires an explicit exact-host allowlist.
What should be done if remote image fetching is required?
Upgrade to 2.1.0-incubating and configure an exact-host allowlist. Only allowlist hostnames whose DNS and HTTP services are trusted.
How can I determine whether my application needs remediation?
Review whether the application uses fesod-sheet 2.0.2-incubating and accepts user-controlled image URLs during spreadsheet writing. Also check whether UrlImageConverter is permitted to fetch remote URLs and whether those URLs can use attacker-controlled hostnames.