Not ready for a demo?
Join us for a live product tour - available every Thursday at 8am PT/11 am ET
Schedule a demo
No, I will lose this chance & potential revenue
x
x
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
Unordered list
Bold text
Emphasis
Superscript
Subscript

The vulnerability was a Server-Side Request Forgery (SSRF) triggered during document preview generation. A file upload feature allowed attackers to upload malicious .odt files, which were then processed by LibreOffice. This let the attacker force requests to AWS metadata services and extract temporary credentials.
The attack chain worked as follows: Upload .odt file via the “upload by URL” feature. Backend passed it to LibreOffice for thumbnail generation. LibreOffice fetched external resources defined in the document XML. Payloads pointed to 169.254.169.254 (AWS metadata endpoint). Metadata containing AWS credentials was embedded in the generated preview. The CDN hosted the preview, leaking the secrets back to the attacker.
LibreOffice supports dynamic content fetching through xlink:href attributes inside .odt files. This allowed attackers to trick it into fetching internal services. Without restricting document update modes, LibreOffice will blindly follow these links, making it an ideal SSRF vector.
AWS temporary credentials are short-lived access keys provided to workloads (like EC2 instances or EKS nodes). If stolen, they can grant attackers access to: AWS Secrets Manager S3 buckets Internal services Even though temporary, they are powerful enough to escalate into long-term breaches.
The platform used a client-side extension whitelist (assetTypeVsSupportedExtensionsMap). By manipulating request parameters, the attacker uploaded unsupported file types like .html and .odt. Because validation wasn’t enforced server-side, the malicious files slipped through.
SSRF is when an application makes requests to attacker-controlled URLs. In cloud environments, SSRF is especially dangerous because it can access metadata services (169.254.169.254 on AWS), leaking secrets that grant access to cloud resources.
The credentials were embedded inside a thumbnail PNG. OCR struggled with clarity, spacing, and formatting. Manual reconstruction was required to piece together the access keys. This extra step highlights how attackers can stealthily hide sensitive data inside media assets.
Disable external resource fetching in LibreOffice (UpdateDocMode.NO_UPDATE). Enforce server-side file validation for uploads, not just client-side. Isolate document processing in sandboxed environments with no network access. Restrict metadata service access using AWS Instance Metadata Service v2 (IMDSv2). Log and monitor thumbnail generation processes for unusual traffic.
They are increasingly common because many SaaS platforms allow upload by URL and rely on third-party processors like ImageMagick, LibreOffice, or FFmpeg. These processors often fetch external content, creating SSRF opportunities.
This case shows that chained vulnerabilities (file upload + LibreOffice parsing + CDN hosting) can escalate into major breaches. It underscores: Why third-party tools need hardened configurations. How cloud metadata services remain prime SSRF targets. Why security reviews must consider document conversion and media pipelines.

.png)



Koushik M.
"Exceptional Hands-On Security Learning Platform"

Varunsainadh K.
"Practical Security Training with Real-World Labs"

Gaël Z.
"A new generation platform showing both attacks and remediations"

Nanak S.
"Best resource to learn for appsec and product security"





.png)



Koushik M.
"Exceptional Hands-On Security Learning Platform"

Varunsainadh K.
"Practical Security Training with Real-World Labs"

Gaël Z.
"A new generation platform showing both attacks and remediations"

Nanak S.
"Best resource to learn for appsec and product security"




United States11166 Fairfax Boulevard, 500, Fairfax, VA 22030
APAC
68 Circular Road, #02-01, 049422, Singapore
For Support write to help@appsecengineer.com


