By Juan Simón Cardona - Security Engineer
When a company in the energy sector launched a new website built on a third-party CMS, the setup seemed straightforward. An administrator logs in, publishes content, and the site updates automatically. All looks clean, simple, and efficient right?….RIGHT?.
They hired us for a one-week grey box penetration test. The goal was to find out how secure the system actually was before an attacker could answer that question for them.
What we found was not a single catastrophic vulnerability. It was three medium-severity issues that, in isolation, looked entirely manageable. Together, they represented a complete attack path that had never been triggered, and would not be, because we found it first.
Finding One: Session Cookies Without the Right Flags
During initial testing, we identified that the CMS session cookies were missing both the HttpOnly and SameSite security flags. Without HttpOnly, any client-side script can read and steal a session cookie. Without SameSite, the browser does not restrict which requests can carry those cookies, opening the door to cross-site request forgery.
On its own, this finding was medium severity. The kind of thing that goes into a report, gets noted, and sometimes waits a few sprints before anyone addresses it.
Finding Two: An Upload Function That Trusted Everything
The CMS allowed administrators to upload and publish content. The problem was in how that content was handled. Any HTML tags included in the upload were parsed and rendered by the browser. Scripts included in the content would execute without restriction.
The system trusted its administrator completely. But that trust had a quiet implication: any malicious script uploaded through the admin panel, whether by accident or through deception, would run on the public-facing website as well as the dashboard. Not just once. On every page load, for every visitor.
Again, medium severity in isolation. The kind of finding that warrants a fix but rarely causes immediate alarm.
Finding Three: A URL That Could Do the Work for You
The third finding is where the chain came together. During testing, we discovered that if an administrator clicked on a specially crafted URL, the CMS would interpret that click as a legitimate content upload request and execute it automatically. No confirmation screen. No additional verification. The content would go live on the public site immediately.
This meant a real attacker would not need to break into the system. They would only need an administrator to click a link in an email or a message. The rest would happen on its own.
What the Chain Could Have Looked Like
An attacker crafts a URL that embeds a malicious script inside a forged upload request. The link gets sent to an administrator. The administrator clicks it. The CMS processes the request, uploads the script, and publishes it to the live site. Every visitor who loads any page on the site executes that script.
From that point, the attacker could steal active sessions, deface pages, or redirect visitors to phishing sites. Without ever gaining direct access to the system. None of this happened. But the conditions for it were fully in place.
Lessons From This Engagement
The client believed the system was secure because no single part of it appeared critically broken. That is the assessment most organizations make, and most of the time it is reasonable. Vulnerability scanners can score these individually and produce a report that reads as manageable.
What scanners do not do is follow the chain. Understanding how findings interact, how one weak point becomes the condition for exploiting the next, is the work that requires a human tester paying attention to the full picture.
This site was assessed before any of this could become a real incident. The findings were documented, remediation guidance was provided, and the team now knows exactly what to address. The attack path existed. It was never used. That is precisely the point.
Exfil Security conducted this engagement as a grey box penetration test over a one-week period. All client references have been anonymized. The vulnerability chain described in this article was identified and reported before any malicious exploitation occurred.
