Tyan / MiTAC Computing PSIRT: For Tyan, this vendor's firmware is unmeasurable from public data

Impact

For Tyan, this vendor's firmware is unmeasurable from public data - the only substantive Tyan BMC vulnerability in the public record, the S5552 TLS private key disclosure, was published by a third-party research lab rather than the vendor, and there is now no vendor channel at all through which fixed firmware or future advisories could be obtained. An operator with Tyan hardware in the fleet has a BMC with a known credential-grade disclosure bug and no path to a fix. For Advantech the situation is different but leads to the same operator conclusion: a working PSIRT exists, so subscribe to it, but do not expect it to cover server BMC or BIOS firmware, because it never has. Tyan has been absorbed into MiTAC Computing; www.tyan.com now serves a TLS certificate for *.mitaccomputing.com that does not match its own hostname, www.tyan.com.tw is a stub linking onward to MiTAC, and mitaccomputing.com returns HTTP 403 to automated clients. Advantech, checked alongside as an industrial-server vendor, does run a real and actively maintained PSIRT at advantech.com/en/security-advisory with ACIRT/AQIRT advisory IDs and an RSS feed - but every advisory on it covers IoT, wireless and software products, with no BMC or BIOS content.

Who can reach it

Not an attack path - a vendor-continuity and disclosure gap. It applies to any operator carrying Tyan-branded server boards, which persist in secondhand and budget capacity builds long after the brand's own support channel has gone.

What to do

For Tyan hardware, assume no firmware fix will arrive. Approach MiTAC Computing directly through a sales channel if you need firmware, and otherwise treat these nodes as permanently unpatched: replace the BMC TLS certificate with one you control, isolate the management VLAN with an explicit allowlist, disable IPMI-over-LAN and virtual media, use per-node unique credentials, and plan the hardware out of the fleet on a defined timeline rather than indefinitely. For Advantech, subscribe to the ACIRT feed but keep server firmware tracking on a separate mechanism, since the feed does not cover it.

References

Related entries

• DDR4 / LPDDR4 DRAM - Target Row Refresh mitigation: Many-sided Rowhammer defeats the in-DRAM Target Row RefreshCVE-2020-10255 · DDR4 / LPDDR4 DRAM - Target Row Refresh mitigationUnscored
• Imagination PowerVR GPU driver - memory residue: An unprivileged application gets the GPU driver to hand backCVE-2021-0891 · Imagination PowerVR GPU driver - memory residueUnscored
• Linux HID/amd_sfh - shift out of bounds: A shift operation in the AMD Sensor Fusion Hub driver exceeds the maximumCVE-2023-53703 · Linux HID/amd_sfh - shift out of boundsUnscored
• Linux perf/x86/amd - general protection fault from a NULL event on enable: A subtle race lets cpucCVE-2025-68798 · Linux perf/x86/amd - general protection fault from a NULL event on enableUnscored
• Apache CloudStack: unsanitized backup repository options inject OS commands onto the KVM hypervisor hostCVE-2026-47359 · Apache CloudStack NAS backup provider (addBackupRepository / updateBackupRepository)Unscored
• DMTF SPDM specification DSP0274 1.4 (FINISH transcript definition): A specification-level defect rather thanCVE-2026-61810 · DMTF SPDM specification DSP0274 1.4 (FINISH transcript definition)Unscored