Understanding ArcGIS Server SOE Compromise

Today 10/14/25, Reliaquest (a security vendor) published a summary about how an ArcGIS Server extension was made by a malicious actor to facilitate on-going persistence after initial compromise via other mechanisms.

This issue does NOT affect ArcGIS customers by default, has been confirmed as an issue by only one customer, and requires multiple configuration steps not in alignment with best practices.

Esri’s incident response team worked with both the customer and the security organization to facilitate investigation efforts.  While the initial write-up by Reliaquest mistakenly referred to internal Esri documentation updates being required, they will be clarifying they suggest customers refer to our existing security best practices documentation, specifically, we recommend the ArcGIS Enterprise Hardening Guide which is updated on a regular basis.

What are the circumstances necessary for this to occur?

1. The ArcGIS Server Manager interface was exposed for general Internet access – Customers should limit access to management interfaces by Internet users. As mentioned in our best practices, don’t expose management interfaces to the Internet.
2. Multi-factor authentication (MFA) was not used – Exposing management interfaces and not utilizing MFA for user accounts should never be utilized as clarified in best practice documentation.
3. While logs were not available back to initial time of compromise, the above issues likely resulted in the malicious user’s ability to administrate the ArcGIS Enterprise system and deploy a custom Server Object Extension (SOE).  The SOE was NOT the initial source of compromise, but was instead utilized as the gateway for passing information and maintaining persistence in the system.  Customers should regularly validate the security posture of their deployment as described in the best practices documentation – This includes ensuring there are no unexpected extensions/plugins installed.
4. Last, but not least, the permissions of the ArcGIS Server service account were elevated to full administer/root which was implemented by the customer as part of troubleshooting an issue, and the permissions were NOT returned to the defaults/best practices. The SOE would have failed if the excessive permissions were not put in place.

Bottomline, this case demonstrates that when a deployment implements numerous layers counter to best practices, a deployment may be compromised. 

The SOE specifically being used for passing traffic and as a persistence mechanism is novel, but implementing security best practices would have prevented this issue.   If some of the circumstances above seem familiar for your operations, you should immediately work on implementing the guidance within the ArcGIS Enterprise Hardening Guide.  Bonus item, we also strongly recommend ensuring you have a Web Application Firewall (WAF) to further mitigate such risks and provide stronger awareness of attacks, which was also a basic component missing from the customer’s deployment.

• Esri Software Security & Privacy