This advisory reports a defect in our own publishing, not a threat. No customer data, product, service or third party was affected. Nobody outside Lifted Holdings caused it and nobody outside Lifted Holdings was harmed by it. It is published because the failure mode generalises to any organisation that publishes an llms.txt, a structured-data block, or a machine-readable feed. Version 1.0.
We published a security advisory, found our own conclusion was wrong on re-testing, and withdrew it with a public correction about ninety minutes later. We corrected the advisory page. We did not correct the four other places we had already published the same claim — including llms.txt, the file AI assistants read to describe a company, and a STIX 2.1 bundle published for other defenders to ingest programmatically. Those kept asserting the withdrawn finding for roughly five more hours, until an audit caught them.
The part worth your time is Section 4. Our first sweep searched for the word we had used — cloaking — and reported the feed clean. The claim was in the feed. It had been written out as the raw observations that produced it, with the word absent. A word search cannot find a paraphrase, and the name is the first thing a paraphrase drops.
Verifiable against our own published history. The withdrawn claim, the correction notice that withdrew it, and the corrected surfaces are all public. The correction notice is in LH-2026-001, Section 6. The surfaces named below are live URLs you can fetch yourself. We are describing our own mistake, so you should not have to take our word for any part of it.
On 2026-08-06 we published advisory LH-2026-001. Version 1.0 asserted that a phishing host performed per-IP “burn-after-view” cloaking, on the basis of reproducible connection resets. Re-testing from a second, independent network vantage point showed the identical requests returning HTTP 200 in the same minute. The resets had been produced by an in-path phishing filter on our own network egress — not by the attacker. We withdrew the finding and published a correction notice roughly ninety minutes after release.
The correction reached the advisory page and stopped there. A later audit of every surface we publish found the withdrawn claim still live in three of them, and a separate counting error in a fourth. The advisory page — the thing we looked at to confirm the correction had landed — had been correct the entire time. That asymmetry is the whole lesson: the surface you check is the one you already fixed.
Four defects were confirmed and corrected, all on the same day. The claim had been public in its stale form for roughly five hours after the human-readable correction went up.
Read this before quoting any other part of this advisory
What this is. A defect in Lifted Holdings' own publishing process, found by Lifted Holdings, reported by Lifted Holdings, and fixed the same day. The generalisable finding is that a correction applied to a human-readable page does not propagate to the derived machine-readable and AI-facing copies of the same claim, and that a keyword search is not sufficient to find those copies.
What this is not
It is not a vulnerability, a breach, an incident, or a report about anyone else. No customer data, product, service or third-party system was involved or affected. It makes no claim about any vendor, and it does not revive or restate the withdrawn finding — the withdrawn finding remains withdrawn, and nothing here should be read as walking that back.
It is also not a measured claim about how AI assistants actually described us. We did not run a controlled test of what ChatGPT, Perplexity, Gemini or any other system said about Lifted Holdings before or after the fix, and we hold no such observation. What we establish is that the file we publish for those systems to read contained a claim we had retracted. What any given assistant did with it on the day is unknown to us and we assert nothing about it.
We claim no novelty. Stale caches and unsynchronised derived copies are an old problem. What we think is worth publishing is the specific modern shape of it — llms.txt and machine-readable indicator feeds as first-class published surfaces that no editorial workflow currently covers — and the concrete reason our own search for it failed.
All times UTC on 2026-08-06.
| Time | Event |
|---|---|
| ~18:2x | LH-2026-001 v1.0 published, asserting per-IP cloaking at stage 2. |
| 19:48 | v1.1 published. The cloaking finding is withdrawn after re-testing from a second egress; a correction notice is added to the advisory. The advisory page is now correct and stays correct. |
| ~19:5x | A sweep of the published indicator files for the string cloak is run. The IOC CSV is corrected. The STIX bundle is reported clean. It was not clean. |
| 22:40 | LH-2026-002 published. Its own summary line carries the miscount described below. |
| ~00:1x(2026-08-07) | A full audit of all eight published surfaces against the corrected record. Four defects confirmed after an independent verification pass. Corrected, redeployed and resubmitted for crawling. |
| Surface | Consumed by | Defect |
|---|---|---|
| /llms.txt | AI assistants describing the company | Withdrawn claim — described LH-2026-001 as covering “per-IP cloaking that defeats automated URL scanning”. |
| lh-2026-001.stix.json | Defenders ingesting indicators programmatically | Withdrawn claim ×2 — two objects still described the behaviour. Neither used the word cloaking. See Section 4. |
| /llms.txt | AI assistants | Miscount — “three published abuse-reporting addresses that bounced”. Two bounced. The third was our own security@liftedholdings.com, which was never published and never existed, so it never bounced. The error appeared in the one section written to demonstrate that we count carefully. |
| /security/advisories/ | Readers, search engines | Instrument unnamed — cited a Google Safe Browsing verdict without stating that it was read from the Safe Browsing engine row on a VirusTotal report rather than queried from Google directly. Incomplete rather than false, but corrected on the same principle. |
This is the part we would ask other people to take away, because it is the part that beat us twice.
When the finding was withdrawn, we swept the published files for the term we had used. The IOC CSV matched, and was fixed. The STIX bundle returned no match, and was recorded as clean.
The STIX bundle was not clean. The retracted claim was in two of its objects, written out as the constituent observations that had produced it rather than as the conclusion we had drawn from them:
"...it applies Turnstile-gated (HTTPS connection resets versus HTTP 200,
first-fetch-then-reset per source address)."
"Turnstile-gated: HTTPS resets, HTTP 200. Origin host concealed."Neither string contains the word cloaking. Both assert it. first-fetch-then-reset per source address is the per-IP cloaking claim — it is simply the raw observation stated without the label we had attached to it elsewhere.
The generalisable rule
When you retract a claim, search for the behaviour you described, not the name you gave it. A paraphrase drops the name first and keeps the substance. This is worse in machine-readable formats than in prose, because indicator files are written in flattened, telegraphic language precisely to be parsed — the descriptive label is the first casualty of that compression.
The practical form: for each retracted claim, write down two or three distinct ways it could have been phrased without its label, and grep for all of them. In our case reset, per source and HTTP 200 would each have found it. The word cloak did not.
Publishing one advisory put the same claim into eight independently-served artefacts. Editing the advisory updated one of them. This is the enumeration we now audit against, and it is offered as a starting checklist rather than a complete one:
| Surface | Why it drifts |
|---|---|
| The page itself | The one you edit. Always correct, which is exactly why it misleads you. |
llms.txt / llms-full.txt | Hand-written prose summaries of your own content, stored nowhere near it. Nothing regenerates them. |
| Machine-readable feedsSTIX, CSV, JSON indicator files | Written once at publication. Telegraphic phrasing defeats keyword search. |
| Index and listing pages | Carry an independently-written summary of the item, not a transclusion of it. |
| Structured dataJSON-LD description fields | Duplicates the claim in a field nobody reads visually. Feeds rich results. |
| Meta description / OG tags | Same duplication, same invisibility, and it is what a link preview shows. |
| Off-site copiespress releases, syndication, submitted reports | Outside your control entirely once published. Plan the correction path before you publish, not after. |
The last row is the one with no clean answer. A press release or a submitted threat report cannot be edited in place after distribution. We do not have a general solution to offer; what we do is keep an explicit list of every off-site location a claim was sent to, so that a retraction can at least be followed by a correction to the same recipients.
Eight published surfaces were audited in parallel against the corrected record. Every proposed finding then went through a separate pass whose only instruction was to attempt to refute it — including confirming that the quoted text existed verbatim in the file, that it was not in fact correct text narrating the withdrawal, and that the proposed replacement preserved valid markup. Six proposed, six confirmed, four of them substantive.
| Check | Result |
|---|---|
Withdrawn claim absent from llms.txt | 0 matches on the live URL |
| Withdrawn claim absent from the STIX bundle | 0 matches for per-IP and first-fetch-then-reset; bundle re-parses as valid STIX, 30 objects |
| Every remaining occurrence of the term site-wide | Read in context individually. All are narration of the correction — changelog rows, the correction notice, the confidence-table WITHDRAWN row — not assertion of the claim. Those are correct and were deliberately left in place. |
| Publication test suite | 19 pass, 0 warn, 0 fail |
We kept the withdrawal narration deliberately. A correction that erases its own history is not a correction; a reader who arrives at the advisory from an old citation needs to find out what changed and why.
“We corrected the advisory itself within ninety minutes, and I assumed that was the end of it. It wasn't. The file we publish for AI assistants and our machine-readable feed both kept asserting a claim we had just retracted, because the correction never propagated past the human-readable page. If an assistant had described our research that day it would have repeated a finding we no longer stood behind — and it would have been quoting us accurately, because we were still publishing it.”
“We searched for the label and the label wasn't there, so we concluded the feed was clean. The claim was there. It had just been written out as the raw observations that produced it. If you publish a correction, grep for the behaviour you described, not the name you gave it — the name is the one part a paraphrase drops.”
“Your website is no longer your only description of you, and the machine-readable copies rot silently. Nobody notices until somebody quotes one back at you. We are publishing our own defect because we would rather be the example than the cautionary tale someone else writes up.”
— Daniel Wilson Kemp, Founder & Chief Executive Officer, Lifted Holdings LLC
Lifted Holdings LLC is a payments and technology company based in Nashville, Tennessee. Its brands include Lifted Payments and AgeVend.
Commercial interest, stated plainly
Lifted Holdings sells payments and retail software — point of sale, payment processing, vending and signage. It does not sell an anti-phishing product, a browser security product, a threat-intelligence feed, a detection engine, or any SEO, AEO or “AI visibility” service. There is no product this advisory sells, and the finding is a defect in our own work.
| Purpose | Contact |
|---|---|
| Press and analyst enquiries | will@liftedholdings.com · +1-855-678-5142 |
| Report a security issue to us | Vulnerability disclosure policy · security.txt |
| Corrections to this advisory | will@liftedholdings.com — we published a correction against ourselves once already; we will do it again. |
| Version | Date | Change |
|---|---|---|
| 1.0 | 2026-08-06 | Initial publication. Records four defects found by the surface audit and corrected the same day. |
Advisory LH-2026-003 · Version 1.0 · Published 2026-08-06 · TLP:CLEAR ·
liftedholdings.com/security/advisories/2026-003-correction-propagation
© 2026 Lifted Holdings LLC. All timestamps UTC.