top of page

Correcting Our Nissan Call: It Was Their Own PeopleSoft — and We Had the C2 28 Days Early

  • Writer: Patrick Duggan
    Patrick Duggan
  • 1 hour ago
  • 4 min read

On June 29 we published a piece arguing that Nissan's run of breaches followed a single pattern — the data never left through Nissan, it left through a vendor, and "our systems were not compromised" was becoming the most hollow reassurance in breach response. That pattern is real, and it holds for several of Nissan's prior incidents. It does not hold for this one. We are correcting the record, because getting the vector wrong is the kind of mistake that gets defenders looking in the wrong direction.


The June 25 Nissan Americas disclosure is not a vendor leak. It is Nissan's own Oracle PeopleSoft deployment, exploited directly through CVE-2026-35273 — an unauthenticated server-side request forgery that chains to remote code execution in the PSEMHUB component of PeopleSoft PeopleTools 8.61 and 8.62. The crew is ShinyHunters, the same operator Mandiant tracks as UNC6040. The exposed data includes contact details, banking information, Social Security numbers, and tax records for current and former Nissan employees across the United States, Canada, Mexico, and Brazil. This time the company's systems were the point of entry, not a third party's. The honest version of our thesis is narrower than what we published: Nissan has a vendor problem on some incidents and a patch-and-exposure problem on this one.


What makes this worth more than a one-line retraction is what was already in our index when it happened. The ShinyHunters PeopleSoft campaign ran from roughly May 27 to June 9. On May 28 — day two of that window, and twenty-eight days before Nissan said a word publicly — our feed already carried the exact command-and-control endpoint the operators used: a MeshCentral agent reachable at azurenetfiles.net on port 443, dressed up to look like a Microsoft Azure service. We held that precise agent path at a confidence of 80, which is our blocking threshold. A customer pulling our high-confidence feed on May 28 was already positioned to catch traffic to that callback.


Here is the part we are least comfortable with, and the reason this is a correction and not a victory lap. We had the exact malicious URL at blocking confidence, but the bare domain — azurenetfiles.net with no path attached — sat one notch lower, at 70, because it arrived later through a different feed. The consequence is subtle and it matters. A defender matching on the exact URL would have blocked the callback. A defender doing domain-level or DNS-level blocking, which is how most organizations actually enforce this, would not have, because the domain itself had not crossed the line. The operators only had to change the path on the same domain to slip a URL-only block. We were right about the infrastructure and a single confidence notch short on the surface most people defend at.


We have fixed the specific indicator. azurenetfiles.net is now in our feed at confidence 90, which means domain and DNS-tier blocking now matches what URL-exact matching could already do. The more useful fix is the rule behind it: a domain should inherit the highest confidence we have ever assigned to any URL or path observed on it. If we had been enforcing that rule on May 28, the domain would have promoted itself to blocking confidence automatically, and domain-level defenders would have been covered four weeks before disclosure instead of after it. That change is now live in the feed builder. We would rather tell you about the gap and the fix than let a clean-looking timeline imply we had it perfectly the whole time. We did not. We were close, and close has a cost.


The wider campaign is the thing to act on regardless of whether Nissan is your concern. ShinyHunters spent most of this year as a help-desk social-engineering crew — a phone call, an MFA reset, a Salesforce export. With PeopleSoft they did something different: they wrote an exploit and pointed it at a single high-value enterprise application that sits on a lot of corporate networks holding exactly the payroll and identity data extortion crews want. They claim around 300 PeopleSoft instances across more than 100 organizations. Nissan is one named victim. The National Association of Insurance Commissioners is another, and that one was not on any watch list we published — we did not see it coming, and we are saying so. Oracle shipped the patch in its June 2026 Critical Patch Update. If you run PeopleSoft PeopleTools 8.61 or 8.62, CVE-2026-35273 is the line item that cannot wait, and azurenetfiles.net is the first callback to hunt for in your historical logs going back to late May.


We guarantee five percent of anything we publish is wrong. This week the five percent was a vector call, and the receipt that redeemed it was a confidence score one notch too low on the surface that mattered most. Both are now corrected. The intelligence was there. The enforcement edge is where we got sharper.





Her name was Renee Nicole Good.


His name was Alex Jeffery Pretti.

bottom of page