Skip to main content

CVSS 9.6 at the Romanian Senate

— Stefan-Lucian Deleanu

CVSS 9.6 at the Romanian Senate
Photo by Amir Alsharif / Unsplash

Over the years, we have reported dozens of critical vulnerabilities to various public institutions in Romania. While most were resolved quickly, some persisted for months (or even over a year) or reappeared due to the inadequate approach of the officials.

One of the most serious vulnerabilities was recently identified in the Romanian Senate: A vulnerability of Remote Code Execution (RCE) generated by the poor configuration of the legislative opinion system.

What does CVSS 9.6 mean?

CVSS (Common Vulnerability Scoring System) is the international standard for assessing the severity of vulnerabilities. The scale ranges from 0 to 10.

  • 0.0 - 3.9: Low
  • 4.0 - 6.9: Medium
  • 7.0 - 8.9: High
  • 9.0 - 10.0: Critical

A score of 9.6 means that an attacker can gain complete control of the server remotely, without authentication, with minimal effort.

In practice, an attacker could modify everything related to the website 'senat.ro', or anything accessible by the web user running on it.

While we do not know the actual level of risk to which the Romanian Senate was exposed, as such an in-depth analysis would have required breaking the law, it is almost certain that if someone had exploited this vulnerability to gain permanent status, it could have been used to destabilize the Romanian state through a coordinated, parallel attack.

Imagine if, at the same time, 10-20 critical institutions ceased operations, displaying a terrorist message/manifesto on their main page with the intent to destabilize the country's economy.

Unfortunately, that's where we are, and our luck depends solely on the fact that the tensions from the north are still manageable and we are not the primary target in the world of cyberattacks.

What we have discovered:

The Senate platform allows the submission of public opinions on legislative projects, including attachments. The upload form does not validate the types of uploaded files.

I tested it this way:

  1. I have accessed the public opinion form
  2. I have filled in my real details, including the reason as transparently as possible: "Testing suspicion of web server configuration issue," which was visible to the page operator (the official who approves the submissions).
  3. I have uploaded a file .aspx (cod executabil pe serverele Windows/IIS)
  4. A public official approved the opinion along with the executable attachment and provided me with a registration number, which is now accessible. Here.
  5. Accessing the opinion page, the file .aspx The file, which was an upload utility, is executed directly on the server. The file has been deleted in the meantime.

The Senate's IIS server ran any .NET code uploaded by users. Without validation. Without a sandbox. Directly in production.

Potential impact:

With this vulnerability, a malicious actor could:

  • Upload a web shell and gain full access to the server
  • Extract legislative database / documents from the senate.
  • Install ransomware the infrastructure of the Senate
  • Use the server as pivot for subsequent attacks in the institution's network, using it as a proxy.
  • Modify the content of the official Senate website.
  • Uses the server in various complex attacks, with the intention of undermining the credibility of public authorities.

We are discussing a fundamental democratic institutionA successful attack could have created a trust vacuum in state institutions, especially if it was carried out with this intent by a state actor.

Unfortunately, in the case of cyberattacks, it is very difficult to identify the actor behind the actions, which increases the danger and makes even individual actors more "cautious," making it difficult to sanction them and thus discouraging malicious actions.

Therefore, a proactive approach is needed on the blue team (defensive) side.

Chronology:

  • 24.11.2025Loading the utility and submitting the 'opinion'.
  • 25.11.2025Approval of loading, identification of vulnerabilities by me, immediate reporting to DNSC and CYBERINT (SRI)
  • November 26, 2025 (~2:00 AM)The main vulnerability was remedied within a few hours
  • GiftMy test file (amCharts.png) încă există pe server, dovadă că remedierea a fost superficială

The file is still accessible: https://www.senat.ro/uploads/amCharts.png

It is archived:

Wayback Machine

When will it be deleted?

Why do these problems persist?

DNSC and SRI they do not have legal competence to intervene directly in the institutions' systems. They can only provide guidance to local IT teams, who do what they can, know and want to do. Usually the bare minimum, being indifferent to the risks produced.

What I can and know, and want to see: they fixed the code execution, but they didn't check which files remain on the server.

The solution is legislative:

  1. Cybersecurity auditors they must be held criminally liable for the quality of the verifications: negligence in service or intellectual fraud if they sign incomplete audits, having the status of assimilated public officials
  2. DNSC extensive skills are required for direct intervention in critical infrastructure, at least in emergency situations, especially concerning critical public institutions. To protect the autonomy of the assisted institutions, this access must be duly logged.
  3. Technical standards must be mandatorily imposed for any information system of public institutions.
  4. In the short term, the development of passive mechanisms with quick installation that can be made available to public institutions to automatically filter threats (e.g., WAFs).

Trilemma:

We either empower the intelligence services (and the world doesn't want this), or we institutionalize accountability, or we wait to be left without electricity or drinking water when a state actor or a bored teenager finds the next breach.

We choose ourselves, or reality chooses for us, unfortunately.