CVE-2020-0618 – SQL Server Reporting Services deserialization risk and remediation

What is CVE-2020-0618?

CVE-2020-0618 is a deserialization vulnerability in Microsoft SQL Server Reporting Services (SSRS). It was published on 11 February 2020 and carries a CVSS score of 8.8, classed as HIGH. An attacker who can authenticate to the report server can craft a malicious page request that triggers code execution under the service account that runs SSRS.

Related remediation guides

Other vulnerabilities in the same family or affecting the same products:

• Ivanti EPMM CVE-2026-6973 RCE Under Active Exploitation
• CVE-2025-59528 – Immediate steps for Flowise remote code execution
• CVE-2025-34037 – Critical OS command injection in Linksys E‑Series routers

We keep a daily-updated list of vulnerabilities CISA has confirmed as actively exploited, including remediation deadlines.

The United States Cybersecurity and Infrastructure Security Agency (CISA) added this flaw to its Known Exploited Vulnerabilities catalogue on 18 September 2024, and it has been observed in ransomware campaigns. CISA’s guidance is clear: apply the vendor’s mitigations or stop using the affected component if you cannot remediate.

How does the vulnerability work?

SSRS receives page requests that contain serialized objects. During normal operation the server deserialises these objects to rebuild the request context. In the vulnerable code path the deserialization routine does not validate the incoming data sufficiently. An attacker who can send a crafted request can therefore inject a malicious payload that the server deserialises and runs as native code.

Because the code runs under the Report Server service account, the attacker gains the same privileges as that account. In typical deployments the service account has access to the database engine, the file system where reports are stored, and sometimes network resources. That level of access is enough to drop ransomware, exfiltrate data, or pivot to other systems.

The exact class of the flaw is “insecure deserialization”. Public details stop at the NVD description – Microsoft has not released a deep technical write‑up, so we cannot describe the precise gadget chain used. What matters for you is the impact: code execution on any system that hosts a vulnerable SSRS instance and allows an authenticated user to reach the vulnerable endpoint.

Am I affected?

First, confirm whether you are running SSRS at all. If you do not have the Reporting Services role installed, the vulnerability does not apply.

To check, run one of the following commands on the server that might host SSRS:

• Get-Service -Name *ReportServer* (PowerShell) – a service named ReportServer or ReportServer$InstanceName indicates SSRS is present.
• sc query ReportServer (Command Prompt) – returns the state of the service if it exists.
• Look for the registry key HKLM\SOFTWARE\Microsoft\Microsoft SQL Server\Reporting Services – its presence signals an installed SSRS component.

If any of those checks return a result, you have a potential exposure.

Next, verify whether the service is reachable by an authenticated user from outside the host. By default SSRS listens on HTTP/HTTPS ports (usually 80/443) and can be accessed through a web URL such as http://your‑server/ReportServer. Try to open that URL from a workstation that uses a domain account that has at least read access to reports. If you can log in and view reports, you meet the “authenticated attacker” condition.

Because the NVD entry does not publish specific affected versions, you must rely on the vendor’s advisory and the table below, which lists the releases that contain the flaw and the releases that fix it. Compare the build you are running against that table – the table is generated automatically from the official source.

In short, if you have SSRS installed, can authenticate to it, and your build appears in the “affected” column of the table, you are vulnerable.

Mitigation steps

The quickest way to close the gap is to apply Microsoft’s security update for SSRS. Microsoft bundles the fix in the regular cumulative update cycle for SQL Server. Follow these steps:

1. Log in to the server with an account that has local admin rights.
2. Open Windows Update or use the Microsoft Update Catalog to download the latest cumulative update for your SQL Server branch.
3. Run the installer and let it complete. The installer will replace the vulnerable SSRS binaries with the patched ones.
4. After installation, restart the ReportServer service (or simply reboot the server).

If you cannot schedule a full update immediately, Microsoft also provides a temporary mitigation that reduces the attack surface:

• Restrict network access to the SSRS endpoint. Use a firewall rule to allow only trusted IP ranges to reach port 80/443 on the report server.
• Disable anonymous access in the SSRS configuration manager. Ensure only Windows‑authenticated users can reach the service.
• Run the service under a low‑privilege account that has only the rights required to render reports. Do not use a domain admin or a highly privileged service account.

These steps do not replace the patch, but they make it harder for an attacker to exploit the flaw while you arrange for the full update.

If a patch is unavailable

In the unlikely event that you cannot apply the update – perhaps because you run a highly customised environment that cannot be changed – you must either isolate the service or discontinue its use.

Isolation options include:

• Moving SSRS to a dedicated, air‑gapped machine that is not reachable from the internet or from untrusted internal subnets.
• Wrapping the service behind a reverse proxy that performs strict request validation and blocks unknown content types.
• Turning off the web interface entirely and using the SSRS API only from trusted internal applications.

If isolation is not feasible, stop the service and plan a migration away from SSRS. Export any required reports, then move to a supported reporting platform that receives regular security updates.

Verification after remediation

Once you have applied the update or put mitigations in place, confirm the fix worked:

1. Run Get-Service -Name *ReportServer* again and ensure the service is running under the expected account.
2. Check the version string shown in the SSRS web portal (usually displayed on the “About” page). It should match a release listed in the “fixed” column of the table below.
3. Run a vulnerability scanner that checks for CVE-2020-0618 again. The scanner should now report the issue as “patched” or “not applicable”.
4. Review firewall logs to confirm that only allowed IP ranges are reaching the SSRS ports.

If any of those checks still show the vulnerability, re‑run the update or double‑check that the correct cumulative update was applied.

References

• Microsoft Security Advisory for CVE-2020-0618 (link to Microsoft security portal)
• CISA Known Exploited Vulnerabilities catalogue entry for CVE-2020-0618 (link to CISA page)
• SQL Server Reporting Services documentation – configuration manager and service account guidance (link to Microsoft Docs)

See the table below for the exact list of affected and patched releases. Use that table to confirm your build status.

Affected versions

NVD has not published machine-readable version ranges for CVE-2020-0618 yet. Check the vendor advisory for the exact affected and fixed releases before you plan an upgrade.