Oct 5, 2026 · 4 min read

How to tell a vendor's software is end of life without asking them

A response header plus the vendor end-of-life table dates a maintenance gap from outside. On one Coral Gables firm it reads 1,764 days.

Article header: How to tell a vendor's software is end of life without asking them

On September 29, 2026, a group calling itself m3rx listed oterolaw.com on its leak site, claiming "Stolen: 82.5 GB 106,460 Files." The domain belongs to Otero Geeza Law, P.A., formerly Jorge E. Otero & Associates, P.A., at 75 Valencia Avenue, 4th Floor, Coral Gables. The tracker record of the listing is the only source: no statement from the firm, and as of October 5 no press coverage of any kind. Both volume figures are the group's own claims and nobody has corroborated them. A leak-site listing arriving before any statement is the normal sequence rather than a sign that something has gone unusually wrong.

The number worth reading is the file count

82.5 GB is a disk figure. 106,460 files is a description of a business. For a practice spanning real estate, corporate and business law, litigation, probate and trusts, banking and condominium work, a store that size is not a project folder — it is the whole document estate. Transactional files are dense in exactly the material that matters if the claim holds: closing packages with wire instructions and identity documents, association owner rolls, estoppel letters, probate inventories.

A store that large also, almost certainly, includes matters closed years ago, because a transactional file does not get deleted when the deal funds. It gets archived in place. The size of the exposure is therefore set by retention, and retention is a practice-management decision rather than a security one.

The outside view, and what it does not establish

Timeline: PHP branch 7.3 reached end of life on 6 December 2021 with 7.3.33 as its final release. On 29 September 2026, 1,758 days later, m3rx listed oterolaw.com on its leak site. On 5 October 2026, 1,764 days after end of life and 6 days after the listing, the site still returned the header x-powered-by: PHP/7.3.33.

Everything above is either a claim or an inference. The one thing an outsider can actually measure here is the firm's public web surface. On October 5, 2026 at 22:19 GMT, https://oterolaw.com/ answered:

HTTP/2 200
x-powered-by: PHP/7.3.33
server: Apache

php.net's own unsupported branches table puts the end of life for branch 7.3 at 6 December 2021, with 7.3.33 as the last release on that branch — 1,764 days between the day security support ended and the day that header was read. The same single page load printed a PHP notice into the HTML, Undefined variable: texturedBg in /home/…/domains/oterolaw.com/html/top.php on line 107, which establishes that error display is switched on in production and nothing beyond that; its one security consequence is disclosing an absolute filesystem path. The footer reads © 2014.

As of October 5, 2026 no initial access vector has been disclosed for this incident, and none of the above is evidence of one. The website is not the file server. A brochure site on shared hosting and a document management system are normally different machines under different contracts, and firms running current PHP get ransomed too. What the header does establish is narrower and still worth having: the only component of this estate a stranger can grade, grades as unmaintained.

The practice: separate the fixable from the terminal

7.3.33 is the terminal release of its branch. There is no 7.3.34 and there never will be. So for whoever runs this site, remediation was never "apply the update" — it was a major-version migration, which breaks application code, needs a developer who may no longer be reachable, and carries a deadline from nobody. That is the same shape as a vendor train with no fixed release: the scan reports the finding indefinitely, the finding is real, and closing it is a project rather than a patch.

This is the most common reason a known-bad component survives for years, and it is worth splitting out of the backlog explicitly. Two queues, not one:

  • Fixable. A supported release exists in your branch. Schedule it, apply it, close it.
  • Terminal. The branch is dead and the fix is a migration. These will never close on a patch cadence, so stop tracking them as though they will.

The honest cost is why this does not happen on its own. The terminal queue is expensive — developer time, regression testing, and a contract with somebody who will own the code afterward — so it gets deferred while the fixable queue stays tidy and the monthly report looks fine. Splitting the two does not make the work cheaper. It makes a chronic red line legible as a funding decision, which is the only form in which anyone will ever approve it.

If you cannot migrate this quarter, the fallback is placement and monitoring: put the component behind something that terminates requests for it, strip the version banner, and make sure its logs land somewhere a human reads.

What to check this week

  • Run curl -sI https://yourdomain/ | grep -i x-powered-by against your own site, then look that branch up on the vendor's end-of-life page. Repeat it for the three vendors holding your client files.
  • Turn display_errors off in production. One directive, no code change.
  • For every finding you are not closing this month, record whether a fixed release exists in your branch at all. If it does not, it belongs in the terminal queue with a named owner.
  • Confirm who is contractually responsible for the runtime of each hosted site you own. A domain outlives the people who set it up, and the answer is often nobody.
  • Ask practice management how long closed matters stay in the primary document store. That is where a 106,460-file number comes from.

North InfoSec runs AI-assisted security assessments and penetration testing, including the inventory and exploitability work described above. northinfosec.com

← All articles