Priority's Portal Generator Handed Out the Keys to the ERP

The short version

In November 2025, during routine external attack surface work, we found that Priority Software's Portal Generator was giving away the credentials to the ERP system behind it. Not through a clever exploit — through its normal behaviour, to anyone who opened the page.

We reported it to the Israeli National Cyber Directorate the same month. Nine CVEs have now been published, CVE-2026-59499 through CVE-2026-59507: five Critical, three High, one Medium. One of them, CVE-2026-59500, scored 10.0 — the maximum the CVSS scale allows, which requires a flaw to be reachable over the internet, trivial to trigger, need no credentials, need no user interaction, and reach past its own system into others.

This article explains what was exposed and what it means for the businesses sitting behind these portals. It deliberately contains nothing that would help anyone exploit it.

What Portal Generator is

Priority Software is one of the larger ERP vendors in the Israeli market, with an international footprint. An ERP is the system a business actually runs on: customers, orders, invoices, suppliers, payroll, stock.

Portal Generator is the product that lets a Priority customer put a public website in front of that system — the portal where your clients log in to check an order, or your suppliers submit an invoice. It is, quite literally, the front door between the open internet and the company's core business data.

One point matters more than any other, and we will come back to it: these portals are usually not run by the business whose data is behind them. They are run by Priority integrators and service providers who host many customers on shared infrastructure.

What we found

We were not looking at Priority. We were mapping what is publicly reachable for a client, and the same portal kept appearing — different companies, different industries, different hosting, but structurally identical. That is usually a sign you are looking at a product rather than a configuration, and product problems repeat everywhere the product is installed.

The first thing we noticed was mundane. The login page took about thirty seconds to appear. That is slow enough to be worth understanding, so we watched what the page was doing while it loaded.

Before anyone had typed anything, the portal fetched its own configuration from a cloud service. That configuration came back containing the address of the internal ERP server, the gateway in front of it, the application secret, the licence key, and a working API username and password. No login. No token. Any visitor.

The encryption meant to protect those credentials runs in the browser as well, inside the JavaScript the portal sends to every visitor. Code delivered to a browser belongs to whoever is holding that browser, so this is not protection — it is decoration.

How far it reached

Credentials on their own are only interesting if they open something. These opened the ERP's own data interface — and that interface was not scoped to what a portal needs. We asked it how much was behind there.

To be clear about what that list is: those are the tables a business runs on. Not a portal leaking a few settings — the ERP itself, enumerated for anyone who asked.

User records came back the same way.

We stopped there. We did not log in, did not use anyone's credentials, did not retain data and changed nothing. Once a finding is confirmed across several unrelated deployments, continuing to pull data serves the report and nobody else.

Why the scale is the story

These portals are not difficult to find. They share a fingerprint, and a single search returns them by the hundred.

Four hundred and fifteen is a number worth pausing on, but it is not the important one.

Most of these environments do not belong to a single company. They are managed deployments, run by integrators and service providers who host many customers on the same instance. That is the standard way this product reaches the Israeli market. So one of those environments is not a business — it is a book of business.

Follow that arithmetic down and it gets uncomfortable. A few hundred reachable portals. Most of them managed. Each managed one sitting in front of hundreds of companies. Each of those companies holding the records of its own customers, suppliers and staff. By the bottom of that chain you are looking at tens of thousands of businesses and the people whose details pass through them.

An attacker never has to work through that list. They need one environment.

Our clients were covered

Our own clients did not spend the last nine months exposed to this. We confirmed the finding in November 2025, and from that week it went onto our watchlist: client environments running Priority were checked for it, monitored for it, and told about it directly.

They were not waiting on a vendor advisory that had not been written, and they did not learn about it from a CVE record nine months later. That is the practical difference between reading about an exposure and being covered for one — and it is the entire argument for continuous external attack surface monitoring rather than an annual test.

The disclosure

We reported everything to CERT-IL in November 2025 — full technical documentation, reproduction steps, severity assessment and scope. Priority Software was brought into the process. The standard 90-day disclosure clock started and we did what researchers are supposed to do, which is nothing, publicly.

Ninety days passed and we kept waiting. Remediation shipped during 2026. The CVEs were published this month. From private report to public record: nine months.

We waited that long deliberately. Portal Generator reaches customers through integrators, patch adoption is uneven by nature, and we had no way to verify that every deployment had been updated. That is not a trade we were willing to make.

But patching is only half the work. The other half is telling the people who were exposed, and that half is easy to skip. If a portal was open for three years, somebody needs to review the logs, work out whether anyone used it, and meet their own notification obligations. None of that begins until someone is told.

What to do this week

If you run Portal Generator, or you are a customer of a provider who does, send these to your vendor in writing and keep the reply:

• Was my environment affected, and on exactly what date was it remediated?
• Were the exposed integration credentials and application keys rotated afterwards? Patching closes the door; it does not change the locks.
• What logs cover the exposure window, and can access to my data during that period be ruled out — not assumed?
• Was my data held in a shared environment alongside other customers, rather than one dedicated to me?
• What are my notification obligations under applicable privacy law, given an exposure measured in years rather than weeks?

Push hardest on rotation. It is the step most often skipped, and if those secrets were retrievable for years, an unrotated credential means the patch changed nothing for whoever already has it.

If you are the provider rather than the customer, the same questions apply to you multiplied by every business in your book — and they will be asking.

What we are not publishing

There are no reproduction steps here. No endpoint names, no request or response contents, no credential formats, no proof-of-concept code. Every screenshot above has been redacted by us, and where redaction would have left something usable, we removed the frame instead of publishing it.

That is a deliberate choice rather than a temporary embargo. We cannot confirm that every deployment in the field is patched, and a working exploitation path would be most useful to precisely the people we would least like to hand it to. The published CVE records give a defender everything they need to assess their own exposure and act on it. They do not give anyone a starting point.

The full technical documentation remains with CERT-IL and the vendor, which is where it belongs.

The published records

All nine identifiers are public. Severities and weakness classes below are taken from the official records, not from our own assessment — each links to MITRE.

Read down the weakness column and the pattern is hard to miss. Missing authentication, hard-coded credentials, client-side enforcement of server-side security — these are not nine unrelated defects. They are one architectural decision, described nine ways.

HackersEye is a security research team working on external attack surface analysis and vulnerability research. For coordinated disclosure, press enquiries, or help establishing whether your environment was affected, reach us through our contact page.