Apple dyld Zero-Day CVE-2026-20700: The Patch You Shouldn’t Delay

Last updated: Feb 2026 · Related terms: Apple security update, zero-day, dyld, CVE-2026-20700, iOS 26.3, macOS Tahoe 26.3

Quick summary

• CVE-2026-20700 is a memory corruption bug in dyld, a core component involved when apps launch.
• Apple says it may have been used in an “extremely sophisticated” targeted attack against specific individuals on iOS versions before iOS 26.
• Apple’s advisories warn that an attacker with memory write capability may be able to execute arbitrary code.
• Patches are shipped in iOS/iPadOS 26.3, macOS Tahoe 26.3, watchOS 26.3, tvOS 26.3, and visionOS 26.3.

Quick navigation

• What is dyld?
• What exactly is CVE-2026-20700?
• Why this one is urgent
• Optional technical notes (how dyld loads an app)
• Who’s affected + official Apple links
• How to patch (fast checklist)
• Notes for IT / SecOps
• Hard facts for tickets / reports
• References (official first)

What is dyld?

When you tap an app icon, the app doesn’t run as a completely self-contained bundle. It depends on shared Apple frameworks and libraries. dyld is part of the system that connects an app to those shared pieces so it can start and run properly.

That’s why dyld vulnerabilities attract attention: it’s not “one app” or “one feature.” It’s part of the machinery used across the platform.

What exactly is CVE-2026-20700?

Apple describes CVE-2026-20700 as a memory corruption issue in dyld, fixed with improved state management. The advisories credit Google’s Threat Analysis Group for reporting it.

What Apple is telling you (without the legal wording)

If an attacker already has a way to write to memory, this bug may let them go further and run code they choose. Apple also says it is aware of a report that this issue may have been exploited in an “extremely sophisticated” attack against specific targeted individuals.

The phrase “memory write capability” matters. In real incidents, attackers often chain multiple steps: one weakness provides a foothold or a primitive (like a controlled memory write), and another weakness turns that into code execution. Apple does not publish exploit details here, which is common when a bug is linked to high-end targeting.

Why this one is urgent (even if you’re “not a target”)

• Targeted attacks still scale. Once a technique exists, it can spread beyond the first victims.
• Shared components amplify risk. dyld sits on the app start path, so it’s valuable in exploit chains.
• Patch windows shrink fast. Once defenders see confirmed exploitation signals, the “later” option disappears quickly.

Practical takeaway: if your device offers one of the fixed versions below, install it. For organizations, patch high-risk users first.

Optional technical notes (for readers who want the “how”)

This section is optional. You can skip it and still patch correctly. If you’re curious, here’s where dyld fits in the boot-up path of an app.

What dyld does during app launch (high level)

• Reads the executable format: Apple apps are packaged as Mach-O binaries. The file includes “load commands” that describe which libraries it needs.
• Maps code and libraries into memory: dyld maps the main binary and the required shared libraries.
• Resolves symbols: when the app references a function in a library, dyld binds those references to the correct addresses.
• Applies fixups: modern systems use precomputed / optimized fixup data to make startup faster; dyld applies what’s needed at runtime.
• Runs initializers: some libraries have startup routines that must run before your app’s main code begins.

Why memory corruption in a loader is a big deal

“Memory corruption” is a broad category: out-of-bounds writes, use-after-free, and other bugs that can alter program memory in unintended ways. In the worst case, memory corruption can be steered to overwrite pointers or control data — which can lead to executing attacker-controlled code.

Apple’s wording (“attacker with memory write capability”) strongly hints that CVE-2026-20700 is most valuable as part of a chain: once a reliable write primitive exists, a second bug can become the bridge to code execution.

Tiny macOS lab: see what an app links against (safe)

On a Mac, you can inspect which shared libraries an app depends on. This isn’t “exploitation”; it’s a normal developer/admin check.

# Show the macOS version
sw_vers

# Pick a binary and list its linked libraries
# (Example: /bin/ls is simple and always present)
otool -L /bin/ls

Note: DYLD_* environment variables exist for debugging loader behavior, but macOS security features (like SIP/protected processes) can cause those variables to be ignored for many system binaries. That’s normal and by design.

Who’s affected + the fixed versions (with official Apple links)

Apple lists CVE-2026-20700 under the dyld section of its security advisories for multiple platforms. These are the official pages you can cite internally.

Platform	Update that fixes CVE-2026-20700	Official Apple advisory
iPhone / iPad	iOS 26.3 / iPadOS 26.3	Security content of iOS 26.3 and iPadOS 26.3
Mac	macOS Tahoe 26.3	Security content of macOS Tahoe 26.3
Apple TV	tvOS 26.3	Security content of tvOS 26.3
Apple Watch	watchOS 26.3	Security content of watchOS 26.3
Apple Vision Pro	visionOS 26.3	Security content of visionOS 26.3

Apple’s security bulletin index (useful for cross-checking release dates and documents): Apple security releases.

How to patch (fast checklist)

For personal devices

• iPhone / iPad: Settings → General → Software Update → install iOS/iPadOS 26.3
• Mac: System Settings → General → Software Update → install macOS Tahoe 26.3
• Apple Watch: Watch app → General → Software Update → install watchOS 26.3
• Apple TV: Settings → System → Software Updates → install tvOS 26.3
• Vision Pro: Settings → General → Software Update → install visionOS 26.3

Quick verification tip

After updating, confirm the OS version number. On iPhone/iPad: Settings → General → About. On Mac: Apple menu → About This Mac. Aim for 26.3 (or later) on the relevant platform.

Notes for IT / SecOps (real-world operations)

Apple did not publish public exploit indicators here, so the most reliable control is still: patch, then verify versions across your fleet.

• Inventory: use MDM reporting to locate devices below 26.3 on affected platforms.
• Prioritize: patch high-risk roles first (execs, security staff, people handling sensitive data).
• Enforce: apply minimum OS compliance rules where possible.

Hard facts for tickets / reports

• Release date: Apple lists these updates as released on February 11, 2026 (see the platform advisories).
• CVSS (as displayed on NVD): 7.8 (High) with vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
• Weakness class (NVD): CWE-119 (memory safety / bounds issue category).
• Cross-platform: NVD lists the issue as fixed in iOS/iPadOS 26.3, macOS Tahoe 26.3, watchOS 26.3, tvOS 26.3, visionOS 26.3.

---

References (official first)

• Apple security releases (official index)
• iOS 26.3 and iPadOS 26.3 security content (Apple)
• macOS Tahoe 26.3 security content (Apple)
• tvOS 26.3 security content (Apple)
• watchOS 26.3 security content (Apple)
• visionOS 26.3 security content (Apple)
• NVD: CVE-2026-20700 (NIST)
• CVE Record: CVE-2026-20700 (cve.org)

VoidLink on Linux: the questions it forces you to ask (with practical hunting notes)

I’m not going to retell the public write-up. If you’ve read it, the interesting part is what it implies for real Linux fleets: quiet persistence + staged behavior tends to slip through single-signal alerts. The notes below are defensive and aimed at triage and hunting.

Scope: This is defensive analysis based on public reporting. No payloads, no delivery steps, no operational guidance.

---

1) If it’s quiet, what do you correlate?

For threats that aim to blend in, correlation beats signatures. The useful question becomes: what changed, what executed, and what talked out, in the same time window.

Quick baseline checks (recent changes)

# recently modified system binaries (adjust window)
sudo find /usr/bin /usr/sbin /bin /sbin -type f -mtime -7 -ls 2>/dev/null

# recently modified config/service directories
sudo find /etc /lib/systemd/system /etc/systemd/system -type f -mtime -7 -ls 2>/dev/null

These are noisy in large environments, but on a single host during triage they quickly answer “did anything important change recently?”.

---

2) Persistence is the boring part — until it isn’t

Linux persistence often hides in plain sight. The trick is to look for items that are: new, rare, and contextually wrong for the host.

Systemd inventory (what’s enabled, what’s new)

# enabled units
systemctl list-unit-files --state=enabled

# recently changed unit files (common hiding place)
sudo find /etc/systemd/system /lib/systemd/system -type f -mtime -14 -print

Scheduled execution points

# cron locations often used for persistence
ls -la /etc/cron.* /etc/crontab 2>/dev/null

# user crontabs (requires appropriate permissions)
sudo ls -la /var/spool/cron 2>/dev/null

What I personally look for: names that resemble system components, but don’t match the distro’s normal naming patterns, or are owned by unexpected users/groups.

---

3) Process lineage: the most underused signal on Linux

If you have auditd, EDR, or any process telemetry, lineage is where a lot of “quiet” activity becomes obvious.

On-box triage: recent logins + suspicious execution timing

# recent logins
last -a | head

# last boots (useful for aligning "startup" behavior)
last reboot | head

Current process tree (fast sanity check)

# show a readable process tree
ps -eo pid,ppid,user,etimes,cmd --forest | less

Look for short-lived helper processes and odd parent-child relationships (services spawning shells, shells spawning network clients, etc.).

---

4) Network behavior: focus on “unexpected talkers”

IOCs help, but the higher-signal check is: which processes are making outbound connections that normally shouldn’t.

# active TCP/UDP connections with process info (depending on distro/tools)
sudo ss -tpn
sudo ss -upn

# if lsof is available
sudo lsof -nP -i

If your environment supports it, build alerts around “process + destination novelty” rather than static domains alone.

---

5) What breaks in typical detection pipelines

• Overreliance on one indicator: file hash, filename, or single path matches.
• No baseline: you can’t call something “rare” if you never measured normal.
• Weak lineage: you ingest process events but don’t use parent-child relationships.
• Network-only logic: outbound traffic is flagged, but the process context is missing.

---

Summary

The most important “hidden” takeaway isn’t the specifics of VoidLink. It’s the reminder that low-noise threats punish shallow telemetry. If you can correlate persistence changes + lineage + network behavior in the same window, your detection quality improves even when indicators churn.

---

Reference

Public reporting on VoidLink Linux malware

Linux Triage Cheatsheet (high-signal commands I actually use)

This is a compact, practical set of commands for quickly understanding what a Linux host is doing. No theory — just the checks I reach for when something feels off.

---

0) Context: what am I looking at?

# who am I / where am I
whoami
hostname
pwd
date

# OS + kernel
uname -a
cat /etc/os-release 2>/dev/null || lsb_release -a 2>/dev/null

# uptime + load
uptime

---

1) CPU / memory / disk pressure

# live view
top

# better process view if installed
htop 2>/dev/null

# memory summary
free -h

# disk usage
df -hT
du -xh /var 2>/dev/null | sort -h | tail -n 20

---

2) What changed recently?

# recently changed files (last 7 days) in common system paths
# change -7 to match your investigation window
sudo find /etc /usr/bin /usr/sbin /bin /sbin -type f -mtime -7 -ls 2>/dev/null | head -n 200

# recently installed packages (Debian/Ubuntu)
zcat /var/log/dpkg.log* 2>/dev/null | tail -n 50

# recently installed packages (RHEL/CentOS/Fedora)
sudo rpm -qa --last 2>/dev/null | head -n 50

---

3) Process triage (what is running, and who spawned it?)

# quick "what's eating the box"
ps aux --sort=-%cpu | head -n 20
ps aux --sort=-%mem | head -n 20

# process tree (readable lineage)
ps -eo pid,ppid,user,etimes,cmd --forest | less

# environment + open files for a suspicious PID
PID=1234
tr '\0' '\n' < /proc/$PID/environ 2>/dev/null | head -n 50
ls -l /proc/$PID/exe 2>/dev/null
sudo lsof -p $PID 2>/dev/null | head -n 50

---

4) Network triage (who is talking out?)

# active sockets with process info
sudo ss -tupan

# quick view of listening services
sudo ss -tulpen

# DNS config
cat /etc/resolv.conf

# route table
ip route
ip addr

---

5) Users, logins, and auth signals

# recent logins
last -a | head -n 30
lastlog | head -n 30

# current sessions
w
who

# sudo usage (Debian/Ubuntu)
sudo grep -i "sudo" /var/log/auth.log 2>/dev/null | tail -n 50

# sudo usage (RHEL/CentOS/Fedora)
sudo grep -i "sudo" /var/log/secure 2>/dev/null | tail -n 50

---

6) Persistence inventory (the usual places)

# systemd: enabled units
systemctl list-unit-files --state=enabled

# recently changed unit files
sudo find /etc/systemd/system /lib/systemd/system -type f -mtime -14 -print 2>/dev/null

# cron locations
ls -la /etc/cron.* /etc/crontab 2>/dev/null
sudo ls -la /var/spool/cron 2>/dev/null

# shell startup (per-user)
ls -la ~/.bashrc ~/.profile ~/.bash_profile 2>/dev/null

---

7) Logs: fastest high-signal reads

# journal (systemd)
sudo journalctl -p err -n 100
sudo journalctl --since "2 hours ago" | tail -n 200

# kernel messages
dmesg -T | tail -n 120

# auth logs (Debian/Ubuntu)
sudo tail -n 120 /var/log/auth.log 2>/dev/null

# auth logs (RHEL/CentOS/Fedora)
sudo tail -n 120 /var/log/secure 2>/dev/null

---

8) Useful one-liners (quick answers)

# biggest files (fast triage)
sudo find / -xdev -type f -size +200M -printf '%s %p\n' 2>/dev/null | sort -n | tail -n 20

# suspicious: recently executed binaries (if auditd exists and is configured)
# (environment-specific; may not work on all hosts)

# check for unexpected setuid binaries
sudo find / -xdev -perm -4000 -type f 2>/dev/null

---

Notes

• Start broad, then narrow. Time windows matter: change -mtime -7 and log ranges to match the suspected incident window.
• Prefer correlation (process lineage + recent changes + network activity) over single indicators.
• This list is designed for triage and incident response, not performance tuning.

Eclipse fails to start due to missing SWT native libraries

After installing Oracle (Sun) JDK 1.8 and removing OpenJDK on Ubuntu 12.04, Eclipse stopped starting. Below is the startup log captured at failure time.

eclipse.buildId=I20110613-1736
java.version=1.8.0-ea
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=en_US
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.osgi 4 0 2012-11-18 11:45:37.406
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
  no swt-gtk-3740 in java.library.path
  no swt-gtk in java.library.path
  Can't load library: /home/xxx/.swt/lib/linux/x86_64/libswt-gtk-3740.so
  Can't load library: /home/xxx/.swt/lib/linux/x86_64/libswt-gtk.so

  at org.eclipse.swt.internal.Library.loadLibrary(Library.java:285)
  at org.eclipse.swt.internal.Library.loadLibrary(Library.java:194)
  at org.eclipse.swt.internal.C.<clinit>(C.java:21)
  at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
  at org.eclipse.swt.widgets.Display.<clinit>(Display.java:132)
  at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:695)
  at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
  at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:95)
  at org.eclipse.equinox.launcher.Main.run(Main.java:1410)

Diagnosis

Installing Oracle JDK changed the system default Java runtime. Eclipse on Ubuntu 12.04 relies on SWT native libraries compatible with OpenJDK, which were no longer resolved after the JVM switch.

Resolution

Manually link the system SWT libraries into Eclipse’s SWT cache directory.

Ubuntu 12.04 (64-bit):

ln -s /usr/lib/jni/libswt-* ~/.swt/lib/linux/x86_64/

Ubuntu 12.04 (32-bit):

ln -s /usr/lib/jni/libswt-* ~/.swt/lib/linux/x86/

Alternative

Switch back to the OpenJDK runtime expected by the installed Eclipse build:

sudo update-alternatives --config java

What column flags represent in MySQL Workbench

In the MySQL Workbench table editor, column behavior is controlled using a set of predefined flags. These flags map directly to column attributes in the underlying MySQL table definition.

Column flags

• PK — Primary Key
  Marks the column as part of the table’s primary key. Enforces uniqueness and implicit indexing.
• NN — Not Null
  Prevents the column from accepting NULL values.
• BIN — Binary
  For string types, forces binary comparison semantics instead of collation-based comparison.
• UN — Unsigned
  Applies to numeric types, allowing only non-negative values and extending the upper range.
• UQ — Unique
  Creates or removes a unique index for the column, enforcing value uniqueness.
• ZF — Zero-Filled
  Pads numeric values with leading zeros when displayed. Often used together with UNSIGNED.
• AI — Auto Increment
  Automatically assigns sequential values, typically used for surrogate primary keys.

Notes

These flags are a convenience layer provided by MySQL Workbench and correspond directly to column attributes defined in CREATE TABLE statements. Actual enforcement occurs at the MySQL server level.

MySQL Workbench combines schema design, SQL development, and administrative tooling into a single interface, replacing earlier standalone utilities such as MySQL Query Browser and MySQL Administrator.