P7 DarkSword is a kit for iOS 18.4 to 18.7, and Apple fixed all six of its flaws by 11 February 2026

The newest iPhone build this loader will attack was released 337 days before the report

Report URI's post of 9 October 2026 says the loader in front of the DarkSword chain it recovered checks for Safari on iOS 18.4.0 to 18.7.2 and loads the chain only on a match. An update to that post the same day says the implant matches iVerify's P7 DarkSword, with two modules byte for byte identical to iVerify's samples. The top of that range, iOS 18.7.2, was released by Apple on 5 November 2025. iVerify published its P7 report on 8 October 2026, 337 days later (derived). Apple's own notes carry a fix for each of the six flaws that Google Threat Intelligence Group (GTIG) ties to the kit, and the last of them shipped on 11 February 2026, 239 days before that report (derived). Report URI calls 18.4.0 to 18.7.2 the loader's targeting range, not a range it confirmed to be exploitable, and says it did not test the chain on real iPhones.

What those numbers do not establish matters as much as the numbers. They do not show that any UK device was targeted: GTIG names Saudi Arabia, Turkey, Malaysia and Ukraine, and no source read for this briefing names the United Kingdom as a target. They do not show that P7 works on any current iOS build, because nobody reports testing it on one and iVerify's post gives no version range in its prose. They give no count of victims. They do not show that attempts to port the kit to iOS 26 will go on failing, and iVerify's verdict that many bundled variants are "AI slop" is its own judgement, which no one else has tested. They do not show whether Lockdown Mode stops P7, or which vulnerabilities P7 uses if they differ from the original six.

What they do show is where the control sits. The control is an iOS update that has existed for most of a year, and the number that matters is how many of an organisation's phones are still on a build in range. Nobody publishes that. Apple's nearest figure is for devices that used the App Store on 7 June 2026: 14% of all iPhones were on iOS 18 (any build), 79% on iOS 26 and 7% on something older. That caps the iOS 18 share and does not count vulnerable phones. Apple does not split iOS 18 by minor version, the 14% includes builds that carry the fixes, the figure is 125 days old (derived), and it predates iOS 27, which Apple released on 14 September 2026.

Six flaws, six fixes: what Apple, GTIG and CISA each record

GTIG's report of 18 March 2026 lists six flaws that DarkSword uses. We checked each against Apple's security pages for the releases GTIG names, against NVD for the score, and against CISA's Known Exploited Vulnerabilities catalogue (KEV). The vendors' summary of the kit is that it chains browser vulnerabilities to escape the sandbox and reach the kernel. This briefing goes no further into how.

The six flaws in GTIG's table of 18 March 2026, with fix dates and exploitation wording from Apple's own security pages, read 10 October 2026. Zero-day status is GTIG's. Quoted wording is Apple's.

Flaw (GTIG's description)	Fixed in, per Apple	Exploited?
CVE-2025-31277: memory corruption in the Safari JavaScript engine	iOS 18.6, 29 Jul 2025	No Apple wording. GTIG: not a zero-day.
CVE-2025-43510: memory management flaw in the iOS kernel	iOS 26.1, 3 Nov 2025; iOS 18.7.2, 5 Nov 2025. Apple added the entry on 12 Dec 2025.	No Apple wording. GTIG: not a zero-day.
CVE-2025-43520: memory corruption in the iOS kernel	iOS 26.1, 3 Nov 2025; iOS 18.7.2, 5 Nov 2025. Apple added the entry on 12 Dec 2025.	No Apple wording. GTIG: not a zero-day.
CVE-2025-43529: memory corruption in the Safari JavaScript engine	iOS 18.7.3 and 26.2, 12 Dec 2025	Apple: "may have been exploited". GTIG: zero-day.
CVE-2025-14174: memory corruption in ANGLE, a graphics layer	iOS 18.7.3 and 26.2, 12 Dec 2025	Apple: "may have been exploited". GTIG: zero-day.
CVE-2026-20700: a flaw in dyld, the system library loader	iOS 26.3, 11 Feb 2026. No iOS 18.7.x page read lists it.	Apple: "may have been exploited". GTIG: zero-day.

The base scores on NVD are not Apple's, because Apple's pages give no severity. They are CVSS 3.1 scores assigned by CISA's ADP entry, and for the two kernel flaws by NVD as well: 8.8 for CVE-2025-31277, CVE-2025-43529 and CVE-2025-14174, 7.8 for CVE-2026-20700 and CVE-2025-43510, and 5.5, Medium, for CVE-2025-43520.

GTIG's zero-day column splits the six evenly. Three were zero-days when the kit used them: CVE-2025-43529, CVE-2025-14174 and CVE-2026-20700, the same three for which Apple's notes carry its "may have been exploited" wording. The other three were not. CVE-2025-31277 was fixed on 29 July 2025, and the two kernel flaws on 3 and 5 November 2025, within days of the early November 2025 campaign GTIG describes. Apple added the two kernel entries to its pages on 12 December 2025, 37 days after the iOS 18.7.2 release (derived). iVerify's March analysis made the same point: the kernel CVEs were not added to Apple's advisories until the day the browser fixes shipped, and they carry no exploitation wording although they were used in the same attack. So in November 2025 the kit combined one old fixed flaw, two just-fixed ones and three zero-days. From 11 February 2026 every one of the six has had a fix, and every use of them after that date was against a flaw with a fix, including, if P7 uses the same six, the infection iVerify investigated in August 2026, at least 171 days later (derived). From first use in November 2025 (GTIG gives the month, not the day) to the public reports of 18 March 2026 is 108 to 137 days, and to iVerify's P7 report 312 to 341 days (derived).

CISA lists all six in KEV. CVE-2025-14174 was added on 12 December 2025, CVE-2025-43529 on 15 December, CVE-2026-20700 on 12 February 2026, and CVE-2025-31277, CVE-2025-43510 and CVE-2025-43520 on 20 March 2026, two days after GTIG's report and 137 to 234 days after the first fix for each (derived). All six due dates have passed, the last on 3 April 2026. KEV binds US federal agencies, not UK organisations, but a listing is CISA's statement that exploitation is known. The lag between a fix and a listing is the subject of an earlier briefing: Both of today's additions to the exploited catalogue were public for weeks.

What P7 adds, and who is reporting what

iVerify's report of 8 October describes an infection it investigated in August 2026 after an alert on one customer's device. iVerify named the variant after a prefix its authors used in the code they changed. Compared with the variants it usually sees, iVerify says P7 leaves a smaller footprint (less debug logging and fewer injections into running processes), keeps a browser-side marker to avoid exploiting the same phone twice, extracts keychain data into a file on the phone before sending it, where earlier versions copied the keychain database to be processed elsewhere, and takes commands from the operator. Those commands cover files, photos, installed apps, Notes and wallet apps. The implant polls for tasking every 15 seconds, and the operator can change the interval. That is 240 polls an hour and 5,760 a day (derived). Whether that rhythm is visible to a defender depends on the network the phone uses, and iVerify does not say how often it is detected.

iVerify's verdict on P7 itself is the opposite of slop. Of the variants it sees, it says the P7 authors "understood the code they were modifying" and that its changes "demonstrated competence". The "AI slop" phrase is about other variants: iVerify told The Hacker News that many bundled variants are non-working attempts, deployed by unsophisticated attackers from copies of patched kits. Separately, iVerify wrote on 15 September that DarkSword's source code was leaked by a third party soon after the March disclosure, and that it had seen multiple unsuccessful, likely LLM-assisted attempts to update the framework to support iOS 26.x. Censys reported on 7 October a workspace with iOS 26 work that it calls unfinished, with placeholder values, and not a live capability.

Report URI's route is separate from iVerify's customer case. It says a defunct analytics company's domain was re-registered on 15 September 2026 after it expired, and that stores still carrying the company's tag then loaded the new owner's script. The script screens out crawlers and, in Report URI's tests, gave datacentre and VPN addresses an empty response, while some residential addresses received a payload once. Visitors who pass are sold on to scam pages, and one route led to a fake crypto trading site that loaded the chain for Safari on the iOS range above. Report URI says its recovered implant is configured to contact its server every 30 seconds, targets files from more than 25 wallet apps, and is a newer build than iVerify's. It has not attributed the campaign to an operator, and says the crypto lure and brokered traffic suggest a financial motive.

Who has used the kit is a count that changes with the source. GTIG named three users in March: a cluster it tracks as UNC6748 (Saudi Arabia), a Turkish commercial surveillance vendor it names as PARS Defense (Turkey and Malaysia), and a cluster it tracks as UNC6353, which it calls a suspected Russian espionage group (Ukraine). Those are GTIG's attributions, and Lookout, which reported the same Ukrainian infrastructure, uses the same cluster name. Censys wrote on 31 July that the kit leaked through a public code repository and was then in the hands of at least seven, probably eight, unrelated operators. On 7 October it said six had been documented publicly before the one it describes, which it calls Chinese-speaking and cannot attribute to a named actor.

Who reported what about DarkSword, and what each publisher sells, as read on 10 October 2026. The commercial notes are plain statements from each publisher's own pages, not criticism.

Report and date	What it adds	Commercial interest
GTIG, 18 Mar 2026	Six flaws, three zero-days, iOS 18.4 to 18.7, four countries, three named users.	Google sells threat intelligence, and says it develops ANGLE, where one flaw sat.
Lookout, 18 Mar 2026	A loader seen for iOS 18.4 to 18.6.2. Says 18.7.3 and later, and 26.3 and later, are not susceptible.	Lookout sells mobile security and says its customers are protected.
iVerify, 18 Mar, 15 Sep, 8 Oct 2026	The chain table, the source leak, the failed iOS 26 ports and P7.	iVerify sells mobile security and incident response.
Censys, 31 Jul and 7 Oct 2026	Seven or more operators, open directories, an unfinished iOS 26 lead.	Censys sells internet intelligence and attack surface products.
Report URI, 9 Oct 2026	A hijacked analytics tag and a P7-matched build with a newer version.	Report URI sells JavaScript integrity monitoring and ends its post with a trial offer.
Apple, release notes	The fixes, and one note on iOS 18.7.7 that names DarkSword.	Apple sells the phones and decides which models receive which updates.

What is stated, and what is not

Four of these publishers sell products that the finding helps, so each claim below is attributed to its maker. The Hacker News's article of 9 October is a secondary reading of iVerify, Censys and Report URI. We used it as a pointer, and where it differs from a primary we followed the primary. It says Censys described the campaign in August 2026, but the Censys post is dated 31 July 2026.

Questions about P7 and DarkSword, with what the primaries state and what none of them states. Read 10 October 2026.

Question	Stated, and by whom	Not stated
Which iOS builds does it attack?	GTIG: iOS 18.4 to 18.7. Lookout saw a loader for 18.4 to 18.6.2. Report URI: 18.4.0 to 18.7.2 for the P7-matched build.	Any P7 support for iOS 26 or 27. A version range in iVerify's P7 prose. Whether the chain works on 18.7.2: untested.
Who was targeted, and where?	GTIG: Saudi Arabia, Turkey, Malaysia, Ukraine. Report URI: visitors to stores carrying a hijacked tag.	Any UK device. Any P7 target list. The country of Report URI's visitors.
How many victims?	iVerify: one customer's phone in August 2026. Lookout: one possible infection in Ukraine on 12 February 2026. Censys: a server copy of unknown origin held 11 recovery phrases and 179 device folders.	A total for P7, or for any operator.
Who runs P7?	iVerify names no actor. Report URI has not attributed its build.	Whether the authors are the original developers, a buyer or users of the leaked source.
Will LLM-assisted porting to iOS 26 work?	iVerify (15 Sep): multiple unsuccessful, likely LLM-assisted attempts. Censys (7 Oct): iOS 26 modules have placeholder offsets and are not a live capability.	Any successful port, or any test of iVerify's judgement. NVD has no record for the bug Censys labels CVE-2026-31001, and Apple's pages read do not list it.
Is the bundled variant "AI slop"?	iVerify to The Hacker News: many bundled variants are non-working AI slop attempts. iVerify's P7 post: the authors understood the code.	An independent test of either judgement.
Does Lockdown Mode stop it?	GTIG: use Lockdown Mode where an update is not possible. iVerify (March, original chain): without additional bypasses the exploits would not be effective with it on. Apple's page does not name the kit.	Any test of P7 against Lockdown Mode.
Which flaws does P7 use?	GTIG: six for the kit. Report URI: two modules identical to iVerify's P7 samples.	A CVE in iVerify's P7 post. Whether P7 adds or swaps flaws. Censys's registry lists two older, fixed flaws besides the six, one of them "unverified on device".
Is infection rising?	iVerify (15 Sep, in its Coruna section): live and historic attacks on vulnerable iOS versions affect 5% of devices, against 1.5% in August.	The denominator, the population, or whether DarkSword is counted.

Three friendly names, and what each leaves out

"New variant" reads as a new capability against current phones. What the P7 reports describe is new code around the same exploit chain: quieter, more theft, two-way control. The exploited flaws were published and fixed. The word variant is accurate about the implant and silent about the phones it can reach, which is the part a patch policy cares about.

"Exploit kit" suggests something that works against any iPhone. DarkSword works only where a loader decides the phone is on a build it was written for, and Report URI says its delivery screens out crawlers and some networks. Lookout's statement is the other side of the coin: iOS 18.7.3 or later, and iOS 26.3 or later, are "not susceptible" to the vulnerabilities the kit exploits. That is a vendor's statement, and Lookout sells mobile security.

"AI slop" suggests a harmless imitation. iVerify uses it for broken bundles and, in the same week, says the P7 authors were competent. And "update" is a friendly name too. An iPhone XS on iOS 18.7.10 is fully updated by Apple's list, yet Apple lists no iOS 18 fix for the CoreGraphics flaw it fixed on 28 September, and does not say whether iOS 18 is affected (One 29-word Apple sentence names iOS twice and macOS never). The update stops this kit's six known flaws. It does not stop the next flaw, and Censys says an iOS 26 chain using an unknown bug is in development and unfinished.

Which build is enough? The sources differ, and the iPhone model decides

The sources that name an iOS 18 build do not agree on which one is enough, because none was written to answer that question.

What each source says about the iOS 18 line, read 10 October 2026.

Source	Says	Caveat
Lookout, 18 Mar	iOS 18.7.3 or later, and 26.3 or later, are not susceptible.	A vendor's statement. Lookout sells mobile security.
GTIG, 18 Mar	Five of the six flaws fixed on iOS 18 by 18.7.3; the sixth, in dyld, on 26.3. Update to the latest iOS, or use Lockdown Mode if not possible.	Does not say which iOS 18 build is enough.
Censys, 7 Oct	The iOS 18 chains are patched in iOS 18.7.3 and 26.3.	No test shown.
iVerify, 18 Mar	Update to 18.7.6 or 26.3.1, which mitigate all the exploited flaws.	Those were the newest builds that day, not a minimum.
Report URI, 9 Oct	The loader's range ends at 18.7.2; two later-stage flaws are patched in 18.7.2.	A targeting range, not tested on phones.
Apple, iOS 18.7.7 page	Fixes tied to DarkSword first shipped in 2025; 18.7.7 was widened to more devices on 1 April 2026.	No flaw-to-build map. No iOS 18.7.x page read lists CVE-2026-20700.

Our reading, which is inference: the primaries agree that the flaws were fixed during 2025 and early 2026, and they disagree about the smallest sufficient iOS 18 build. The safe rule is not to engineer to a minimum. Take the newest build that exists for the model.

Which build that is depends on the iPhone. Apple's security releases page lists iOS 26 and iOS 27 releases for iPhone 11 and later, so the iPhone XS, XS Max and XR cannot run them. Those three models are the ones still receiving iOS 18 releases: the newest, iOS 18.7.10, was released on 17 August 2026, 54 days before this briefing (derived). By the page's device lists, iPhone 11 to iPhone 16 handsets that stayed on iOS 18 were last offered iOS 18.7.8, on 22 April 2026. They can run iOS 26.7.1 or iOS 27.0.1, both released on 28 September 2026. Apple's iOS 18.7.3 page lists the iPhone XS, XS Max and XR, not iPhone 11 and later. Our inference is that an iPhone 11 to 16 left on iOS 18 was offered no iOS 18 build carrying those fixes until iOS 18.7.7. Apple widened that build to more devices on 1 April 2026 so that users with automatic updates "can automatically receive important security protections from web attacks called DarkSword". The idea of current has moved too: iVerify and Censys write about iOS 26, but Apple released iOS 27 on 14 September 2026 and lists iOS 27.0.1 as the latest. No source read says anything about the kit and iOS 27.

Four measures of how many devices are on iOS 18, with what each does not tell you. Apple's figures are for devices that used the App Store on 7 June 2026.

Measure	iOS 18 share	Why it is not the exposed count
Apple, all iPhones, 7 Jun 2026	14% (iOS 26: 79%, earlier: 7%)	Any iOS 18 build, including 18.7.3 and later. No minor-version split. 125 days old and before iOS 27.
Apple, iPhones introduced in the last four years, same date	11% (iOS 26: 86%, earlier: 3%)	Same limits.
StatCounter, UK, September 2026, mobile and tablet web traffic	11.44% across all iOS 18 labels; 10.05% labelled 18.4 to 18.7	A web-traffic estimate that includes iPads. The 18.7 label mixes patched and unpatched builds, and StatCounter notes a Safari change that misreported iOS 26.1 and 26.2 as 18.6 and 18.7 until a correction on 19 January 2026.
iVerify, March 2026, worldwide	14.2%, about 221.5 million devices, on 18.4 to 18.6.2	iVerify's estimate from third-party data, for the original kit. Not Apple's count.

None of the four is the number that matters, which is the share of an organisation's own phones that are on 18.4 to 18.7.2 or on a model with no fix. Apple's figure does bound the problem: at most one iPhone in seven was on any iOS 18 build when Apple measured (derived from 14%).

UK: iPhones in Cyber Essentials, and who knows which iOS each phone runs

Cyber Essentials v3.3 (April 2026) counts smartphones as devices. Phones the organisation owns are in scope, and so are user-owned devices that access organisational data or services, except devices used only for native voice, native text and multi-factor authentication apps. Software on in-scope devices must be licensed and supported, removed (or kept off the internet) when unsupported, have automatic updates enabled where possible, and be updated within 14 days of release where the update fixes critical or high-risk vulnerabilities, defined as a CVSS v3 base score of 7 or above or the vendor's own description, or where the vendor gives no detail of severity. Apple's notes give no severity, so on the text's own terms the 14-day clock applies. Fourteen days from the 12 December 2025 builds is 26 December 2025, and from iOS 26.3 is 25 February 2026 (derived). Apple released 18.7.3 for the iPhone XS, XS Max and XR on 12 December, so an in-scope one still on iOS 18.7.2 is 288 days past the 14-day mark (derived). For an iPhone 11 to 16, the text does not say whether a move from iOS 18 to iOS 26 counts as an update for the 14-day rule.

Where it does not reach: the requirements do not say how an assessor checks a phone's iOS version, or what to do when a vendor stops supporting a model. Cyber Essentials defines supported software as software for which the vendor has committed to fixes and given a future end date, and the Apple pages read here give none for the iPhone XS, XS Max or XR. That is a question to put to an assessor, not a finding. A phone used only for calls, texts and an authenticator app is out of scope, and whether authenticator data is among what P7 takes is not stated. We covered the same unsupported-software rule for Windows in the same rule applied to unsupported Windows.

What UK and Apple guidance says about updating phones and about Lockdown Mode, and where each stops. Read 10 October 2026.

Source	What it says	Where it stops
NCSC, Keeping devices and software up to date (reviewed 13 May 2025)	Install updates promptly, ideally within a few days. Enforce automatic updates through MDM and monitor with MDM logs or compliance policies. With BYOD, restrict access to corporate data from devices not kept up to date. Replace unsupported devices as soon as you are able.	Names no iOS version or kit. Warns that automatic updates can fail, for example when storage is low.
NCSC, Update by default (reviewed 1 May 2026)	Operating system and application updates should apply automatically as soon as published, completed within 7 days. UK victims of a compromise should report it.	Written for estates in general. Says nothing about phones with no update path.
NCSC, iOS and iPadOS guide (reviewed 13 May 2025)	Lockdown Mode is for users who might be targeted personally by the most sophisticated threats. It cannot be configured through MDM. Most users will not need it.	Last tested on iOS 18.3.1 in February 2025, before iOS 26 and 27. Does not mention DarkSword.
Apple, About Lockdown Mode	Update to the latest software before turning it on. A device in Lockdown Mode cannot be newly enrolled in MDM, and one already enrolled stays managed.	Does not name DarkSword or claim that it stops any given kit.

Who knows which iOS each phone runs? For enrolled phones, the MDM does, if its reporting is switched on and someone reads it. For unenrolled personal phones that read company mail, it is whatever the identity provider records at sign-in. That depends on the product and on how the phone connects, and we did not test any product. The NCSC's BYOD advice is to restrict access for devices that are not kept up to date, which needs the version to be known first.

Keychain and wallet theft means credentials on the phone. GTIG's list of what the original data miner takes includes device keychains, Lookout's includes saved passwords, and Report URI's includes saved Wi-Fi passwords and files from more than 25 wallet apps. Censys says the platform it studied also mines photos and Notes for crypto recovery phrases. Not stated: whether passkeys, or a password manager's vault, are within reach. For a UK organisation the practical reading is that any secret saved in a phone's keychain, Notes or Photos could be taken if the phone is compromised, and a suspected compromise is a credential reset event, done from a different device.

What to do, in the order worth doing

The first four steps find and close the exposure. The next three keep it closed and limit what a compromise would reach. The last makes the response quick.

What could not be verified

The question that exposes the gap

Every flaw in this kit had a fix 239 days before the report, and the newest build its loader attacks is 337 days older than that report. The new variant changes nothing about which phones it can reach. So which phone in your estate is still on a build it was written for, and who could tell you by Monday morning?

Key facts