SSRF in 2025: New Targets and Practical Exploits

SSRF attacks have surged since 2023, roughly 450 percent by some counts. That jump did not happen by chance. Cheap AI-powered scanners and fuzzers can now try thousands of odd URL forms, spot weak filters, and find paths humans miss. The result is fast discovery at scale.

At its core, SSRF tricks a server into making a request it should not. The server becomes a proxy, hitting internal services or cloud metadata that the attacker cannot reach directly. This post shows what changed in 2025, where attackers are aiming now, short case snapshots from this year, and safe ways to test and defend without causing harm.

If you run cloud-first apps or API-heavy platforms, this is for you.

SSRF in 2025 explained: what changed and why it matters for your cloud apps

The biggest shift in 2025 is speed. Automated tools, many backed by AI, can try a wide range of URL shapes, protocols, and redirection tricks in seconds. That speed makes even small input flaws risky. When your app fetches a URL on behalf of a user, the server may follow attacker input and land on internal services, metadata endpoints, or sensitive admin APIs.

Cloud-first teams feel this more. Apps often stitch together many services, APIs, and plugins that call out to the internet. Each call is a door. With SSRF, the door opens from the inside, so the request has more trust, more network reach, and often access to data that is not meant for public users.

What makes 2025 different is that attackers have fresh targets. Cloud metadata has new defenses, but not everywhere. Modern SaaS tools expose APIs by default. AI and LLM add-on systems fetch URLs, process webhooks, and connect to internal plugins. Put that together and SSRF paths multiply.

For a helpful overview of current trends, see Vectra’s guidance on detection and prevention, which also highlights the 452 percent growth curve, in Server-side Request Forgery: How to detect the 452% attack trend: https://www.vectra.ai/topics/server-side-request-forgery.

What is SSRF, in plain English

Picture a website that lets you preview any URL. You paste a link, and the server fetches it. If filters are weak, an attacker could enter a link that points to a private address, like an internal admin page or a cloud metadata address. The server, sitting inside the network, can reach it. The attacker cannot, at least not directly.

Why is that bad? Internal services often trust calls from inside the network. Some expose tokens. Some return admin data. SSRF turns your server into a helpful courier, but it carries secrets to the wrong person.

Why SSRF spiked 450% since 2023: AI tools and automation

Modern scanning tools create many payload styles, toggle encodings, try redirects, and switch URL schemes. They learn what works and try it across thousands of targets. This cuts the time from idea to exploit. It also lowers the skill required. A small mistake in input handling can now show up across the internet in hours.

You do not need a list of payloads to grasp the core point. Volume and variety are up. Filters that worked in 2022 often fail now.

Blind SSRF and attack chaining: from small bug to big breach

Blind SSRF means you do not see the server’s response. Attackers still learn from side effects. They watch logs on their own servers for inbound hits. They time how long a page takes to load. They nudge the server to ping a unique URL, then confirm it happened. With patience, they map reachable hosts and services.

SSRF often pairs with other bugs. Combine SSRF with a weak redirect rule or a permissive proxy, and you can reach deeper systems. Add a misconfigured token service and you get cloud access. In some 2025 cases, SSRF served as the first step to remote code execution or bulk data theft.

New SSRF targets in 2025 that attackers actually hit

Attackers go where the value is. In 2025, that means tokens, admin panels, and automation hooks. Cloud metadata is still hot. Popular enterprise tools add more APIs. AI integrations fetch data for you. Each category has seen real-world abuse.

Google’s threat team wrote about large-scale abuse tied to Oracle E-Business Suite flaws and extortion activity. Their analysis frames how fast attackers move when a pre-auth bug appears: https://cloud.google.com/blog/topics/threat-intelligence/oracle-ebusiness-suite-zero-day-exploitation.

Cloud metadata services (169.254.169.254) and token theft

Clouds still use link-local IPs like 169.254.169.25,4, for instance, for metadata. That endpoint can hold temporary tokens for AWS, Azure, or GCP. Providers have added stronger protections, like IMDSv2 in AWS, but legacy code and misconfigurations keep this path open.

Why it matters: if an attacker steals a role token through SSRF, they can call cloud APIs as your app. With the right role, that can turn into full account control. F5 covered a 2025 campaign targeting EC2 metadata through SSRF on public sites hosted in AWS: https://www.f5.com/labs/articles/campaign-targets-amazon-ec2-instance-metadata-via-ssrf.

Exposed APIs and SaaS: 2025 cases in Oracle EBS, Cisco ISE, and Trend Micro Apex Central

Vendors shipped fixes this year for SSRF issues that attackers probed in the wild. In Oracle E-Business Suite, a pre-auth SSRF path was flagged and patched as CVE-2025-61882. Oracle’s advisory confirms remote exploitation without login: https://www.oracle.com/security-alerts/alert-cve-2025-61882.html. Analysts also documented chaining paths and impacts: https://www.picussecurity.com/resource/blog/oracle-ebs-cve-2025-61882-vulnerability.

Across the broader ecosystem, reports in 2025 described unauthenticated SSRF via API endpoints or parameter tricks in products like Cisco ISE and Trend Micro Apex Central. Outcomes ranged from data access to code execution when chained with other bugs. For context on how fast exploited flaws land on priority lists, see CISA coverage of new additions to the Known Exploited Vulnerabilities Catalog: https://thehackernews.com/2025/10/five-new-exploited-bugs-land-in-cisas.html.

AI and LLM integrations: Custom GPT connectors and webhook SSRF

Teams wired LLMs into workflows in 2025. Plugins, actions, and custom connectors often fetch URLs on your behalf. That fetch happens server-side, which is the core SSRF risk.

Here is the flow, in words. A user prompts a Custom GPT to get data. The GPT calls a connector with a URL. The connector runs on your server, follows the URL, then returns the data to the GPT. If the URL points to an internal resource, the server might reach it. If response data includes tokens or secrets, those can leak back to the user or get stored in logs tied to the chat. Webhook handlers create similar risks when they follow redirects or trust user-provided endpoints.

Practical exploits, safe testing, and real defenses that stop SSRF in 2025

Security testing must be careful, scoped, and legal. Your goal is to prove the risk without touching real internal services or sensitive data. Then, fix the root causes with guardrails that hold up against AI-scale probing.

Build a safe lab and set rules before you test

Set a clear scope, in writing. Get approval from the system owner. Use a staging environment. Point tests only at domains you own, such as a unique subdomain that logs requests. Turn on detailed server logs. Avoid anything that changes data or stresses production systems. Keep an audit trail.

Proving SSRF without harm: signals to look for

• Watch server logs for outbound requests to a unique URL that you control.
• For blind SSRF, compare load times between endpoints that respond fast versus slow.
• Confirm that only your controlled endpoints are hit, not internal IPs or cloud metadata.
• Check your DNS logs for lookups tied to unique hostnames you create.
• Stop testing once you prove the server can reach out on your cue.

2025 case snapshots and lessons you can use today

• Oracle E-Business Suite: Pre-auth SSRF via an API path. Lesson, lock down URL fetch features, sanitize inputs, and apply patches fast. Reference the vendor advisory and fix timeline: https://www.oracle.com/security-alerts/alert-cve-2025-61882.html.
• Cisco ISE: Reports pointed to SSRF via parameters in admin or device enrollment flows. Les: on, Enforce strict allow lists for outbound requests and disable redirects.
• Trend Micro Apex Central: SSRF paired with weak authentication in some paths. Lesson: validate hosts, require auth for URL fetch actions, and restrict egress from the app tier.
• Custom GPT token issues: Connectors and webhooks fetched URLs that could hit internal resources. Lesson: isolate LLM connectors, scrub secrets from responses, and block access to link-local and RFC1918 ranges.

The SSRF defense playbook for 2025: prevent, detect, respond

Strong SSRF defense uses layers. You want strict input rules, network blocks, and runtime detection. You also want to patch fast when vendors ship fixes.

Concrete controls:

• Use strict allow lists for hosts and schemes. Only https and only known domains.
• Disable redirects on server-side fetches, or cap to one redirect with strict host checks.
• Block access to 169.254.169.254 and private address ranges from app containers.
• Add egress filtering so app servers can only talk to approved destinations.
• Segment networks, keep admin services off the default route from app tiers.
• Monitor for unusual outbound requests, such as spikes to new domains or link-local IPs.
• Patch quickly and follow vendor and CISA alerts to catch exploited bugs early. For a broader context on active exploitation, track roundups like this: https://thehackernews.com/2025/10/five-new-exploited-bugs-land-in-cisas.html.

Quick start this week:

• Inventory every server-side URL fetch in your code and plugins.
• Add a host allow list and turn off redirects.
• Block metadata IPs at the network layer.
• Restrict egress from app servers to required services only.
• Enable detailed outbound request logging with alerts on link-local and private ranges.
• Review patches for Oracle EBS and any exposed admin tools.
• Document a response plan for suspected SSRF, including token revocation and key rotation.

Conclusion

SSRF grew fast in 2025 because automation found weak spots we missed. New targets stand out, like cloud metadata, exposed enterprise APIs, and AI connectors that fetch URLs on your behalf. The fixes are not flashy, but they work. Use allow lists, block metadata access, restrict egress, and watch for odd outbound traffic.

Next step, review any server-side URL fetch feature today. Add network blocks for 169.254.169.254 and private ranges. Enforce host allow lists. Schedule a patch and logging check this week. Small moves now can stop the big breaches later.