- SSRF allows attackers to trick your server into fetching resources from your internal IP addresses or cloud metadata endpoints.
- The key difference between CSRF (cross site request forgery) and SSRF (server side request forgery) is that they target completely different victims. While CSRF targets your customers, SSRF attacks your business.
- SSRF attacks have surged 452% because they allow attackers to bypass your edge or perimeter firewalls.
- OWASP battle-tested libraries can unmask the hex, octal, and mixed encodings that attackers use to bypass your IP validation filters.
- Do over-permissioned internal services and admin/dev logins keep you up at night? LastPass Business Max complements metadata access controls to keep your business safe.
SSRF allows attackers to abuse app features – like URL fetching – to access your internal resources.
Read that sentence again.
In real-world terms, attackers are exploiting your site’s features to unlock your entire business.
While you were closing deals, managing payroll, and keeping customers happy, an SSRF attack happened to a company just like yours.
Zimbra, an email and collaboration platform trusted by thousands of businesses, got hit in October 2025.
So, why should you care about an attack with a confusing acronym?
Because in the next five (5) minutes, you’re going to discover:
- How a simple app feature led to the Capitol One breach that cost $190 million
- How this attack weaponizes your own infrastructure against you
- The exact 5-minute conversation to have with your dev team about SSRF prevention & remediation (without alienating them)
What is CWE 918: SSRF (server side request forgery)?
First, let’s start by defining CWE 918: SSRF.
CWE 918 is the official identifier for a security weakness called server side request forgery (SSRF).
“CWE” stands for Common Weakness Enumeration.
It’s a master list of the most common hardware and software security weakness types.
Each CWE has an ID, to provide consistency when talking about the same weakness. A CWE-<ID> is always followed by a description.
In the case of CWE-918: SSRF, we’re talking about server side request forgery, where attackers trick your server into fetching resources from your internal IP addresses or cloud metadata endpoints.
How does server side request forgery work?
According to MITRE, SSRF happens when your web server accepts a request (like an URL request) from a user and fetches data from that URL without any restrictions.
“Server side” means the attack happens on your server, not the customer’s device.
“Request” means your server is asking another system for info. For example, a user asks your server to fetch a product image from an URL.
And you’re right if you’re thinking, “That sounds like a legitimate request.”
However, “forgery” means the attacker tricks your server into sending a request it should never send, like asking for metadata from your cloud environment.
The scary part is, your server will comply and think it’s doing exactly what it’s supposed to do.
Cross site request forgery (CSRF) vs server side request forgery (SSRF): What’s the difference?
The key difference between CSRF and SSRF is that they target completely different victims.
|
Cross site request forgery (CSRF) |
Server side request forgery (SSRF) |
|
Tricks your customer’s browser into making an unauthorized request |
Tricks your server into making an unauthorized request |
|
Targets your customers |
Targets your infrastructure |
|
May change a user’s password or transfer money out of their account without permission |
May expose your database, internal APIs, or cloud credentials |
While CSRF targets your customers, SSRF attacks your business.
Why should you care about server side request forgery (SSRF)?
Does your business have a website or app that accepts URL requests from customers?
If so, you’re a prime target for SSRF attacks.
Here's why SSRF is particularly dangerous:
- Cloud environments are prime targets: Whether your business uses AWS, Azure, or Google Cloud, attackers can leverage SSRF to steal your cloud credentials, move laterally, and exfiltrate your data.
- That 452% surge in attacks isn’t random: Attackers target SSRF vulnerabilities because they allow them to bypass your perimeter or edge firewalls.
What can happen if your business experiences a server side request forgery attack?
A SSRF attack can lead to:
- The theft of database passwords, API keys, & cloud service credentials
- Exposure of customer PII
- Remote code execution
- Use of your server as a proxy for attacking other businesses
What were the lessons learned from the Capital One SSRF breach?
Remember the Capitol One SSRF attack? Even in a shared responsibility model, relying on AWS best practices alone is no longer enough. Identity-centric controls must be prioritized so that compromise of any one role doesn’t expose metadata-heavy environments.
In 2019, just ONE SSRF flaw exposed the data of 100 million+ people in the U.S. and 6 million in Canada.
The breach cost Capital One $190 million in penalties.
According to Zscaler, here's how the attack went down:
- Capitol One’s app ran on an EC2 instance (virtual server) behind a WAF (web application firewall). The instance had an IAM role attached to it.
- The attacker was able to send an SSRF payload through the WAF because the firewall was misconfigured.
- This allowed her to trick the EC2 instance into calling the AWS metadata service.
- In response, the service returned temporary AWS credentials for the IAM role attached to that EC2 instance.
- The EC2 instance’s IAM role had overly broad S3 permissions.
- The attacker leveraged those permissions to make API calls to the S3 service and dump the data from it. That’s how millions of customer records were exposed, decrypted, and exfiltrated.
The key takeaway from the Capital One breach for your business? You can get enterprise-grade protection without an enterprise-size budget.
Here's how: By prioritizing identity-centric controls.
Alongside traditional network safeguards:
- Configure IAM roles with least privilege permissions to limit which internal services can talk to sensitive backends (for metadata-based access)
- Enforce long, unique passwords and FIDO2 MFA (for human logins i.e. admins, dev team, staff).
- Turn on built-in alerts in your SaaS tools to identify suspicious logins.
What are some recent examples of SSRF?
Recent examples of SSRF are:
- CVE-2025-25065: SSRF vulnerability in Zimbra’s RSS feed parser
- CVE-2025-61882: Oracle E-Business Suite (EBS) zero-day vulnerability, with multi-stage exploit chain involving SSRF
CVE-2025-25065
The year: 2025
What happened: An SSRF vulnerability was discovered in Zimbra’s chat proxy feature.
CVSS score: 5.3 (medium severity)
Key risk: As you probably know, Zimbra lets users add RSS feeds so that new items from those feeds appear in their own dedicated folders in your inbox.
With unpatched versions, the Zimbra server will fetch and parse the URLs you supply without validation. This means attackers can submit an RSS feed URL that points to your internal or local service.
Thus, they can trick the Zimbra server into fetching info it shouldn’t touch, such asconfiguration files, login credentials, customer PII, and financial records.
What it means for your business: If you use Zimbra 9.0.0 before Patch 43, 10.0.x before 10.0.12, and 10.1.x before 10.1.4, your server (and internal data) could be at risk.
What to do: Your dev team has likely already applied Zimbra’s patch for affected versions. A quick check to confirm can provide peace of mind.
CVE-2025-61882
The year: 2025
What happened: A critical flaw lets attackers access Oracle Concurrent Processing, a core component of Oracle E-Business Suite (EBS) that manages and runs background tasks like generating reports and processing invoices.
CVSS score: 9.8 (critical)
Key risk: Attackers can combine SSRF with server side injection tricks like CRLF injection and unsafe XSLT processing to achieve remote code execution.
In other words, attackers can send web requests that let them run commands on your Oracle EBS server, with the potential to steal data or plant ransomware.
What it means for your business: If your company uses affected EBS versions and the system is reachable from the internet, attackers can access your financials, employee records, and customer PII.
What to do: Since it’s a high priority fix, your dev team has likely already applied Oracle’s security update for CVE-2025-61882. Again, a quick check to confirm can provide peace of mind.
Server side request forgery (SSRF) prevention and remediation: The 5-minute conversation to have with your dev team
Your dev team already has security measures in place. And it’s likely they’ve read the OWASP SSRF prevention cheat sheet.
The following is a 5-minute check: “Are our defenses current against SSRF exploits in the wild?”
Check #1 Input validation
Why this matters: The Oracle attack used hex and octal encoding that bypasses SSRF IP validation filters that only check for standard decimal dotted notation like “127.0.0.1.”
These alternative formats equal numerically blocked internal IPs but appear as strings.
They exploit parsers that fail to normalize them to decimal form before validation.
Quick check: Are we using OWASP-recommended libraries like:
- Apache Commons Validator (Java)?
- Library ip-address (JavaScript)?
Both validate IPs by parsing sneaky formats like hex, octal, and mixed encodings that attackers use to disguise blocked internal IPs and bypass your filters.
Check #2 Strict access controls
Why this matters: SSRF attackers continue to target internal services.
Quick check:
- Are we enforcing least privilege permissions for metadata access?
- Alongside this, are we securing our SaaS app logins and using hardware-backed authentication (FIDO2 security keys) for admin access?
If you aren’t yet managing the second through a Secure by Design password manager with FIDO2 support and SaaS Monitoring, this is the upgrade you need. Try it now with your free trial of LastPass Business Max (no credit card required).
Check #3 Allowlist strategy
Why this matters: The Zimbra attack proved that “trusted” destinations can become attack vectors.
Quick check: Are we monitoring for domains on our “safe list” (allowlist) suddenly resolving to internal IPs? OWASP provides a Python script to run automated checks for this purpose.
Check #4 Network segmentation
Why this matters: If your public app can directly reach internal services, one SSRF attack can compromise ALL your sensitive data.
Quick check: Have we implemented OWASP recommendations for network segmentation to block illegitimate calls at the network level?
Check #5 URL scheme restrictions
Why this matters: Attackers use URL schemes like file://, ftp://, and gopher:// to force your app to access local files or resources.
Quick check: Do we explicitly whitelist only HTTP/HTTPS schemes and reject everything else, according to OWASP recommendations?
Walk through the above five (5) checks. Your dev team can confirm immediately where you’re solid and where there might be gaps.
For any gaps, ask:
- What can we do to close them?
- What’s the timeline for SSRF remediation?
And most importantly, document everything (what works and what doesn’t).
Sources
Cybersecurity News: Critical Zimbra SSRF vulnerability let attackers access sensitive data
Vectra: Server side request forgery
GreyNoise: New SSRF exploitation surge serves as a reminder of 2019 Capital One breach
Krebs on Security: What we can learn from the Capitol One hack
ACM Digital Library: A systematic analysis of the Capital One data breach: Critical lessons learned
CVE cybersecurity database: CVE-2025-25065 - Exploiting SSRF in Zimbra’s RSS Feed Parser
OWASP: SSRF prevention cheat sheet
Veracode: SSRF prevention guide
