AMD's SEV-SNP bulletins came 90 days after its August firmware date; server BIOS fixes due Nov and Dec

90 days separate AMD's August firmware date from its two bulletins

AMD published two security bulletins about AMD Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) on 10 November 2026: AMD-SB-3059 (CVE-2026-0462) and AMD-SB-3061 (CVE-2026-40671). Each has one revision entry, "2026-11-10 Initial version". The tables print a date earlier than that. In AMD-SB-3059 every EPYC row gives an "SEV FW Release Date" of 2026-08-12, and in AMD-SB-3061 every EPYC row gives a "Microcode Release Date" of 2026-08-12.

Derived: from 12 August to 10 November 2026 is 90 days (19 days left in August, 30 in September, 31 in October, 10 in November). Derived: the Instinct MI300A row in AMD-SB-3061 is dated 2026-09-21, which is 40 days after 12 August and 50 days before the bulletins. The Platform Initialization (PI) firmware, which AMD says goes to server makers (OEMs) for their BIOS updates, has only target months: "Nov'26" for AMD-SB-3061 and "Dec'26" for AMD-SB-3059 on the EPYC server lines, and January, February or April 2027 for embedded parts.

What this does not establish. It does not show that anyone was exposed for 90 days. The bulletins do not say who could obtain the August firmware or microcode, when the issues were found, or whether an attack has been used: neither page contains the words exploit or "in the wild". It does not show that a host is safe because a release date has passed, because the tables list PI firmware, SEV firmware and microcode in separate columns and the bulletins do not say which of them a given host needs. Targets are AMD's plans, not delivered updates. AMD makes the processors and wrote both bulletins, so what they leave out is AMD's choice of what to print.

Read time. The lead saved both pages at about 17:30 UTC on 13 November 2026. The saved page data carries a last updated time of 10:41 at UTC minus 6 on 10 November on both, which is 16:41 UTC (derived). Anything AMD revised after the save is not included. This builder fetched nothing.

Zoom

What each bulletin says, side by side

The two bulletins describe two different flaws, in two different places, with two different attackers. AMD's own summaries are below, followed by a table of the fields that matter.

AMD-SB-3059 summary: "A malicious hypervisor may manipulate Memory Mapped I/O (MMIO) routing, potentially compromising SEV-SNP integrity in some AMD processors."

AMD-SB-3061 summary: "A security researcher reported a flaw in VMRUN error handling that may expose Secure Encrypted Virtualization -Secure Nested Paging (SEV-SNP) guest register data to a privileged attacker via a Transient Scheduler Attacks (TSA) side channel attack resulting in a loss of confidentiality. AMD has assessed the report and plans to release mitigations."

Zoom

Who the attacker is. AMD-SB-3059 says "a malicious hypervisor". AMD-SB-3061 says only "a privileged attacker" and does not say how that attacker obtains the position, or whether it is a hypervisor, a host administrator or something else. This site's inference, not AMD's: on a rented confidential VM, the hypervisor and the privileged software around it belong to the cloud operator, so an attacker with that position is, in practice, the operator or someone who has taken the operator's place. The bulletins do not say that, and they do not say which cloud providers run affected hosts.

Credit. AMD thanks "External Researchers" at ETH Zurich for AMD-SB-3059, and names ETH Zurich and Google for AMD-SB-3061. This site names the two organisations and no person. The researchers' papers are not part of the saved pages, so nothing here describes their methods.

Which processors, and what the SEV table in AMD-SB-3059 says

AMD-SB-3059 carries a small table headed "SEV Table" with one row: CVE-2026-0462, SEV "N", SEV-ES "N", SEV-SNP "Y". Read plainly, AMD says this flaw applies to SEV-SNP and not to plain SEV or SEV-ES guests. AMD-SB-3061 has no such table. Its summary names SEV-SNP guest register data, and the bulletin does not say whether SEV or SEV-ES guests are affected. This site does not guess.

Both bulletins list the same five EPYC server lines: 7003, 8004, 8005, 9004 and 9005. AMD-SB-3061 adds one accelerator line, AMD Instinct MI300A. Both list embedded EPYC parts separately. Both carry the note: "*Note: Products believed to not be affected by the listed CVEs are not included." The bulletins do not name the products they consider not affected, so an absent product is not named as safe either.

The date columns, row by row

The tables use two kinds of date. A full date such as 2026-08-12 is a release date. A phrase such as "Target release planned for Dec'26" is a plan. This site reads Nov'26 as November 2026 and Feb'27 as February 2027. Because AMD prints only a month, each target is a range of days; the ranges below are derived from the first and last day of the month.

The longest gap on the EPYC server lines is therefore 141 days (derived): 12 August to the last day of December. That is the latest end of AMD's own planning range for the AMD-SB-3059 PI firmware, and it is a plan, not a commitment.

What each row requires. AMD's sentence is: "AMD plans to release to the Original Equipment Manufacturers (OEM) the Platform Initialization (PI) firmware versions on the target dates listed below. Please contact your OEM for the BIOS update specific to your product(s)." The tables then list PI versions, and separately SEV firmware (3059) or microcode (3061). The bulletins do not say whether the August SEV firmware or microcode closes either issue on its own, whether the PI is needed in addition, or how the August versions reach a host that has not had a BIOS update. They also do not say whether an operator can load the August versions without the PI. This site reports what is printed and does not infer a rule.

The bulletin fields, copied as printed, row by row

AMD prints no indicators of compromise, no detection rules, no commands and no exploit material in either bulletin, and this section adds none. What it prints are the CVE records, the vectors and the firmware, microcode and attestation tables. They are copied below so that a defender can match them against what an OEM or cloud provider reports. Table layout is this site's; every value is as printed.

The two CVE records. What it is: the description, score, vector and weakness class AMD prints for each issue. What to do: keep them with the host inventory, and compute your own CVSS score, which AMD itself invites.

AMD-SB-3059, CVE-2026-0462
Insufficient Granularity of Access Control in AMD Secure Encrypted Virtualization (SEV) firmware could allow a malicious hypervisor to potentially redirect access to MMIO memory resulting in loss of guest memory integrity.
CVSS Base Score 5.9: CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:N/SI:H/SA:N
CWE-1220: Insufficient Granularity of Access Control

AMD-SB-3061, CVE-2026-40671
Incomplete cleanup during VMRUN error handling could allow access to a Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) guest register state, potentially resulting in information disclosure and impacts to confidentiality.
CVSS Base Score 4.9: CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N
CWE-459: Incomplete Cleanup

The AMD-SB-3059 firmware and attestation table. What it is: per EPYC line, the PI version, its target month, the SEV firmware version with its release date, the mitigation bit and the TCB[SNP] value, then the SEV table. What to do: confirm with the OEM or cloud provider which PI version and SEV firmware version each host runs, and check the TCB[SNP] value in the attestation report against the row for that family.

Product | CVE ID | PI Mitigation | PI Release Date | SEV FW Mitigation | SEV FW Release Date | Mitigation Bit | TCB Values for SNP Attestation
AMD EPYC™ 7003 Series Processors | CVE-2026-0462 | MilanPI-SP3_1.0.0.L | Target release planned for Dec'26 | 1.3A.03 | 2026-08-12 | Mitigation Bit=8 | TCB[SNP]=0x1F
AMD EPYC™ 8004 Series Processors | CVE-2026-0462 | GenoaPI_1.0.0.K | Target release planned for Dec'26 | 1.3A.4 | 2026-08-12 | Mitigation Bit=6 | TCB[SNP]=0x1E
AMD EPYC™ 8005 Series Processors | CVE-2026-0462 | TurinPI_1.0.0.C | Target release planned for Dec'26 | 1.3A.0A | 2026-08-12 | Mitigation Bit=12 | TCB[SNP]=0x8
AMD EPYC™ 9004 Series Processors | CVE-2026-0462 | GenoaPI_1.0.0.K | Target release planned for Dec'26 | 1.3A.4 | 2026-08-12 | Mitigation Bit=6 | TCB[SNP]=0x1E
AMD EPYC™ 9005 Series Processors | CVE-2026-0462 | TurinPI_1.0.0.C | Target release planned for Dec'26 | 1.3A.0A | 2026-08-12 | Mitigation Bit=12 | TCB[SNP]=0x8

SEV Table
CVE ID | SEV | SEV-ES | SEV-SNP
CVE-2026-0462 | N | N | Y

The AMD-SB-3061 PI and microcode table. What it is: per line, the PI version, its target month and the microcode versions with their release dates. What to do: ask the OEM or provider for the microcode version running on each host. The bulletin prints no attestation value for this CVE, so the version has to come from the operator.

Product | CVE ID | PI Mitigation | PI Release Date | Microcode Mitigation | Microcode Release Date
AMD EPYC 7003 | CVE-2026-40671 | MilanPI-SP3_1.0.0.L | Target release planned for Nov'26 | Milan-B1 0x0A0011E1; Milan-B2 0x0A00124E | 2026-08-12
AMD EPYC 8004 | CVE-2026-40671 | Genoa_100J Patch 3 | Target release planned for Nov'26 | Siena RSDN - A2 0x0AA0021F | 2026-08-12
AMD EPYC 8005 | CVE-2026-40671 | TurinPI_1.0.0.C | Target release planned for Nov'26 | 0x0B002176 | 2026-08-12
AMD EPYC 9004 | CVE-2026-40671 | Genoa_100J Patch 3 | Target release planned for Nov'26 | Genoa RS-B1 0x0A10115B; Genoa-RS-B2 0x0A10125B | 2026-08-12
  (second microcode line, same row) | Bergamo RSDN-A2 0x0AA0021F | 2026-08-12
AMD EPYC 9005 | CVE-2026-40671 | TurinPI_1.0.0.C | Target release planned for Nov'26 | Turin Classic -BRH C1 0x0B002176; Turin Dense - BRH D B0 0x0B101067 | 2026-08-12
AMD Instinct MI300A | CVE-2026-40671 | Patch version 0x0A900110 | 2026-09-21 | 0x0A900110 | 2026-09-21

The embedded parts. What it is: the embedded EPYC rows of both bulletins. Versions read Version TBD. What to do: if embedded EPYC parts carry SEV-SNP workloads, ask the vendor of the device for the date, because AMD prints only a target month.

AMD-SB-3059 (CVE-2026-0462), embedded:
Embedded 7003 Series Processors CVE-2026-0462 Version TBD Target release planned for Feb'27
Embedded 8004 Series Processors CVE-2026-0462 Version TBD Target release planned for Feb'27
Embedded 9004 Series Processors (formerly codenamed "Bergamo") CVE-2026-0462 Version TBD Target release planned for Feb'27
Embedded 9004 Series Processors (formerly codenamed "Genoa") CVE-2026-0462 Version TBD Target release planned for Feb'27
Embedded 9005 Series Processors CVE-2026-0462 Version TBD Target release planned for Feb'27

AMD-SB-3061 (CVE-2026-40671), embedded:
Embedded 7003 Series Processors CVE-2026-40671 Version TBD Target release planned for Jan'27
Embedded 8004 Series Processors CVE-2026-40671 Version TBD Target release planned for Apr'27
Embedded 9004 Series Processors CVE-2026-40671 Version TBD Target release planned for Apr'27
Embedded 9005 Series Processors CVE-2026-40671 Version TBD Target release planned for Feb'27

AMD's own instructions. What it is: three sentences that frame the tables, copied exactly. What to do: follow the first, and treat the others as the limits of what AMD is saying.

AMD plans to release to the Original Equipment Manufacturers (OEM) the Platform Initialization (PI) firmware versions on the target dates listed below. Please contact your OEM for the BIOS update specific to your product(s).
*Note: Products believed to not be affected by the listed CVEs are not included.
Specific CVSS scores may change subject to your implementation. We encourage you to calculate CVSS scores independently for your system.

Where the two bulletins differ from each other

Three differences sit between the two pages and are left as differences.

The same PI name carries a November target in one bulletin and a December target in the other, for the 7003, 8005 and 9005 lines. The bulletins do not say whether one PI release carries both fixes with the second bulletin's date being the one that counts, or whether the name is reused for two builds. A customer asking an OEM for "the BIOS built on MilanPI-SP3_1.0.0.L" needs to ask which date and which fix that BIOS contains. That is this site's reading of the printed names, not an AMD statement.

What the attestation fields let a verifier check, and what they do not

AMD-SB-3059 is the only one of the two that prints attestation values. Two columns, "Mitigation Bit" and "TCB Values for SNP Attestation", give one number each per family. They sit in the same rows as the SEV firmware versions.

What a verifier can do with them. For CVE-2026-0462, AMD prints the TCB[SNP] value and the mitigation bit number it associates with the fix, family by family. A relying party that receives an SNP attestation report from a host can look at the TCB values the report carries and compare them with this table for the host's family. That is the use the column heading implies; it is this site's reading, because the bulletin gives no procedure.

What the bulletin does not say.

• Whether the check is equality or "at least this value", and where in a report the "Mitigation Bit" is read from. The glossary that the page links is not part of the saved pages.
• How an attestation report behaves on a host that has not applied the fix: whether it reports a lower value, the same value, or fails. The table prints the fixed values only.
• Whether loading the August SEV firmware changes the reported values without the PI. The values sit beside the SEV firmware column, but nothing says loading it alone does that.
• Anything about CVE-2026-40671. AMD-SB-3061 prints no mitigation bit and no TCB value, only PI and microcode versions. From the bulletin alone, a verifier has no printed attestation value to look for.

This site also does not compare the values across families. 0x1F, 0x1E and 0x8 are printed for different families and the bulletin does not say they share a scale.

Why it matters (this site's observation). A report that attests successfully shows what the host says about itself. Treating success as proof that the host is patched would be the friendly-name fallacy: the label "attested" is doing the work of a patch check. The check exists only if the verifier reads the TCB fields against a published table, and for CVE-2026-40671 no such table is printed.

Scores and wording: a note on the vector

AMD scores CVE-2026-0462 at 5.9 and CVE-2026-40671 at 4.9 on CVSS 4.0. Both vectors begin AV:L (local), AC:L, AT:N and PR:H (high privileges required), with UI:N. In AMD-SB-3059 the only impact metric not set to N is SI:H, which is a high impact on integrity of a subsequent system; the vulnerable system metrics VC, VI and VA are N. In AMD-SB-3061 the only impact metric not set to N is VC:L, a low confidentiality impact. The metric expansions are the standard CVSS 4.0 ones and were not read from a saved page in this build; the scores are AMD's and were not recomputed.

AMD adds its own caution: "Specific CVSS scores may change subject to your implementation. We encourage you to calculate CVSS scores independently for your system."

This site's observation, and not AMD's. The text AMD prints for the two issues is "loss of guest memory integrity" and "a loss of confidentiality". The scores are 5.9 and 4.9. The lower numbers follow from a local vector that needs high privileges. The premise of confidential computing, as this site understands it, is that the party holding those privileges (the host operator and its hypervisor) is the one the guest does not trust. A score built on "privileges required: high" therefore describes the attacker that the feature is meant to exclude, so a reader running confidential VMs for that reason may want to weigh the impact wording above the number. Whether it matters for a given workload depends on what sits in guest registers and memory, and the bulletins do not say. AMD's score is AMD's.

What AMD states, and what it does not

What to do, in order

AMD's own advice in the bulletins is two sentences. Contact the OEM for the BIOS update specific to the product, and calculate CVSS scores independently for your own system. Everything in the list below is this site's suggestion for anyone running confidential VMs on EPYC with SEV-SNP, and is labelled so.

The question the bulletins leave open

If a relying party looked at the attestation reports it received this week, could it say which of its hosts carry AMD's August SEV firmware, and does it hold a written date from each provider and OEM for the BIOS that carries the fix?

Key facts