skip to content

How I got RCE in

/ 15 min read

PT Version

tl;dr: Found a very simple arbitrary file upload vulnerability that lead to RCE in a CMS widely used in Portuguese government portals - one of which was Long disclosure timeline in less critical governmental entities raises a possible discussion about vulnerability mitigation policies in portuguese public entities and the need for a national CVD.


Throughout my years of browsing and pentesting Portuguese applications I always found myself having the habit of finding weird operational behavior. This often drives me into curiosity rabbit holes.

I sometimes indulge this curiosity and try to passively analyze these applications - sometimes by merely inspecting the web requests or the web frameworks that are used.

Yes this cover image was made with GPT-4.0 - the prompt I used is on my Github

I’ve reported several vulnerabilities to Portugal’s CERT (CERT.PT) over the years - whether because I stumbled upon a government portal that had some vulnerabilities or a commercial application that would allow a user to make purchases for free.

This process commonly known as “responsible” or “ethical” disclosure has been recently argued by ENISA and other european entities as an essential factor in passive cyber security operations.

The sometimes unspoken reality is that there are a lot of security researchers who have done this process and reported these types of critical vulnerabilities in an ethical manner - even though there WERE no formal guidelines in place for us to do so in a secure manner. There are, however, perhaps even more individuals who have identified critical vulnerabilities on governmental portals but are too afraid to report them due to the lack of disclosure guidelines.

But there appears to be some push in the right direction. Since 2016, several countries have created a vulnerability disclosure program that would aid researchers in the process of ethical disclosure:

Something smells odd

In 2020, after some high profile hacks against Portuguese entities via vulnerable web applications, I kept asking myself - How vulnerable are our government websites?

I curiously browsed <> and started seeing multiple requests containing the endpoint /wwwbase.


Given this parameter’s “uniqueness” - and after some basic google fu, I immediately identified other governmental portals containing this directory (makes it incredibly easy to fingerprint too right?).


One name kept popping up in the source code: “Masterlink”.

This was found to be the major CMS (Content Management Suite) used by these websites for web page control and backend interface.


This parameter wwwbase seemed strange - and most security people and even web developers would find its appearance odd - since it creates the assumption that one would be able to access files present before the base application directory by requesting elements without wwwbase.

This and the following other indicators made me more curious about this application and its security features:

  • Seemingly complex and functionality-rich CMS;
  • Usage of ASP and ASP.NET (old programming language with sometimes unmaintained code);
  • Primarily used in public governmental entities. (Unfortunately) Public entities are less likely to do internal penetration tests that identify possible issues in these applications, since this is the case - it leaves itself untested against an outsider.

Given the variety of websites that I found using this CMS platform, I decided to explore them and their features. Given the existence of a login backend - the following flow is often used when researching vulnerabilities in CMS or Platform-as-a-Service providers.

CMS / PaaS
CMS / PaaS
Find bug
Find bug
Registration feature 
Registration featur…
Site A
Site A
Site B
Site B
Explore app
Explore app
Explore bug
Explore bug
Authenticated features
Authenticated features
Registration feature 
Registration featur…

One of these Masterlink websites happened to be - which allows public registration:


I curiously started going through the HTML source code of this page.

Why looking at Javascript matters

Within the registration page, I once again started merely inspecting all the new Javascript files that were now being used.


One of these files was /processos/include/campoHTML/editorHTML.js which caught my attention given its name. HTML editing is usually a backend functionality and its endpoints are not ideally presented in the frontend.

Within this Javacript file, the following portion of its contents was found:


A file upload handler - most likely used by the backoffice dashboard to upload images and static files - was found along with its ASHX upload endpoint.

The bug

As you can imagine by now, the bug was pretty straightforward. I curiously tried to upload a .PNG file toward this endpoint using the following command:

curl -s -i -A "" -X POST -F "image[][email protected]" ""

The response returned:


And the file had been uploaded successfully:


I was slightly baffled so I replicated the same request towards and the behaviour was the same. (!)

Ok sure I can upload arbitrary images towards but can you do the same with ASP files? The answer was yes.

Proof of concept and WAF issue

So as it turns out, you could interact with this endpoint and upload arbitrary ASHX files without any restriction or authentication.


An RCE proof-of-concept was made that executes the whoami command and prints out its result. A report was then immediately sent to [email protected].

cat report | gpg -o - -a -e -r [email protected] - | vim -

I also noticed that is behind the Imperva Incapsula WAF, so another question was raised: Why didn’t the WAF block the uploaded file?

As I later found out, Incapsula WAF blocks ASP code within any of its multipart uploaded files - however - for whatever reason the WAF does not inspect ASHX files. (!)

Disclosure timeline

Date of Metric
August 17th, 2020Developed RCE Proof-of-Concept to;
August 17th, 2020Received ack from CERT.PT as they coordinate report to affected entities (CEGER for and CMS provider Masterlink;
August 19th, 2020I verify that the vulnerability has been fixed and PoC removed from;
August 19th, 2020CERT.PT asks for a list of other affected entities;
August 19th, 2020I provide CERT.PT with a list of affected domains identified given the google dork;
August 20th, 2020Acknowledgement from CERT.PT as they coordinate reports to affected entities;
May 3rd, 2021I report to CERT.PT that there are still 2 governmental (GOV.PT) domains and 1 governmental entity vulnerable to RCE;
March 14th, 2023Report to CERT.PT that there are now 2 vulnerable endpoints and that a public disclosure of this finding will be released at the end of April 2023;
Nov 21st, 2023I connect with the DPO (Data Protection Officer) of SEG-SOCIAL.PT on Linkedin in order to coordinate the vulnerability fix of the last GOV.PT domain;
Nov 21st, 2023I report to SEG-SOCIAL’s SOC the nature of the vulnerability and the associated vulnerable endpoints;
Dec 16th, 2023I verify that the vulnerability has been fixed in the last GOV.PT domain. Still 1 governmental domain left vulnerable (ICNF -;
Jan 2nd, 2024I send another email to CERT.PT explaining that is still vulnerable and that I plan on releasing this blog post on 10th of January;
Jan 28th, 2024I track down 2 people from ICNF’s IT team and contact them on LinkedIn explaining the situation;
Jan 30th, 2024One of the IT people from ICNF responds on LinkedIn with an email address of a ICNF sysadmin;
Jan 30th, 2024I email an ICNF sysadmin with the vulnerability details and how to achieve a possible fix;
Feb 5th, 2024Still no response - I forward the same email to [email protected];
Feb 13th, 2024The website was found to be no longer vulnerable since it returns an error when uploading ASP and ASHX files;
March 12th, 2024I release this blog post.

Is this a healthy disclosure timeline?

When it comes to a disclosure timeline the main success factor is how fast and efficiently the critical vulnerability gets fixed across the affected systems. In this case, Portugal’s CERT was exceptionally proactive at coordinating a fix for its most critical vulnerable portal taking less than 1 day between the vulnerability report and the mitigation.

Masterlink also quickly released a new CMS version where this vulnerability was fixed. Most portals were found to no longer be vulnerable in the span of a few months.

Certain governmental websites - however - did not follow this quick mitigation process. Having three years passed since the initial report, there were still one domain and one governmental associated websites vulnerable.

I thought about the possibility that these entities no longer have valid licensing to the CMS making software updates no longer a viable option since its a general occurrence when it comes to vulnerability patching.

After this process, I found that there seemed to exist some resistance between CERT.PT and the last affected entities on their ability to properly fix the vulnerability in a promptly manner.

Even though the people behind CERT.PT are extremely professional and competent - I found that they perhaps lack in funding and resources when battling these tricky vulnerability disclosures towards public entities.

There is also the factor of enforcement policy, where perhaps CERT.PT does not have proper guidelines to enforce vulnerability fixes across governmental entities, and is constricted by merely reporting them toward the affected IT team.

What we’re doing right

Portugal’s CERT, Masterlink and the top governmental entities like CEGER, DGS and SGE moved fast in fixing critical security vulnerabilities in its affected entities.

CERT is also in the process of getting approval for their proposal of a CVD (Coordinated Vulnerability Disclosure) that would aid this process of vulnerability disclosure.

Portugal does not have a CVD policy in place. However, a task force including the Portuguese National Cybersecurity Centre (CNCS), public authorities and stakeholders from the cybersecurity community was convened to work on a proposal for establishing a policy at the national level which anticipates the need to amend the criminal law. The task force presented a proposal with a comprehensive CVD policy and legislative amendments. The proposal is now being examined by decisionmakers.

Even though we don’t have a formal CVD, CERT.PT still manages to successfully play the role of a ”vulnerability coordinator” when it comes to quickly reporting tricky vulnerabilities to critical governmental entities while managing to safeguard the integrity of an ethical disclosure.

What we’re still lacking

Unfortunately, most public entities in Portugal do not perform regular offensive security audits, so security disclosures are an essential factor when it comes to protecting governmental assets.

Portugal still does not have a national CVD (Coordinated Vulnerability Disclosure) that legally protects researchers and facilitates coordination with affected entities. ENISA still recommends the following standards when it comes to implementing a CVD.


In this program, the national CERT.PT team would play the part of “coordinator” where vulnerability disclosure would be triaged very much like a Vulnerability Disclosure Program - throughout multiple phases until it gets mitigated by the vendor.

According to ENISA’s standard, this “coordinator” would validate the vulnerability, triage, and report it to the affected entities.

The “coordinator” would also manage a multiparty response with the affected entity and develop workarounds for when vulnerabilities are not as simple to fix (i.e., software out of licensing).

“Protection of security researchers. Researchers involved in vulnerability discovery are often exposed to criminal or civil liability. The legal liability and responsibilities of security researchers should be fully clarified to enable them to continue their work without fear of prosecution.” - EFF Coders’ Rights Project Vulnerability Reporting

Overall, I still think CERT and CNCS should have more funding and human resources attributed to tackle and facilitate this process.