CVE-2026-111943: v1 xpack backport status and a low-impact upgrade path

[liudong-geek]

Hello maintainers,

This is a version/support and safe-maintenance question about the already-public eMudhra/emSign CA incident and CVE-2026-111943, not a report of a new vulnerability or evidence of exploitation. No identifying production details or logs are included.

Sanitized version context

• Ubuntu 22.04, Linux amd64.
• 1Panel v1.10.21-lts, built with Go 1.23.3 and the xpack build tag.
• In our 2026-10-24 check, the official v1.10.34-lts amd64 package matched the published checksum but reported Go 1.24.11. We have not obtained evidence of an event-specific backport for that build; this is not a claim that no vendor backport exists.
• We have read the October security notice and understand that v2.4.1 uses Go 1.27.3 to address CVE-2026-111943. The upstream Go fix baselines are 1.26.10 and 1.27.3.

Questions

1. Applicability and backports: Is the v1.10.21-lts xpack build affected, and which actual outbound HTTPS features use the relevant verification path? If a v1 build is patched or unaffected, could you provide its exact build/version and the supporting advisory or technical evidence?
2. Supported v1 target: Is there an official v1 security build for this incident? Please specify the version/build, compiled Go version or equivalent backport, supported architecture, download location and checksum/signature. Does v1.10.34-lts include such a backport? If v1 no longer receives security fixes, please clarify its support status and the supported migration target.
3. Actual xpack trust behavior: For update checks/downloads, the app store, licensing and cloud-storage clients, does this build use system roots, custom/embedded roots, or another trust source? Are certificate-chain and hostname checks enabled? Are roots cached, and how can a system trust change be safely reloaded and verified? We do not infer the xpack behavior from the public !xpack implementation.
4. Temporary mitigation: Is there an officially supported mitigation that does not require a major-version migration? Please identify the exact supported setting/file, required service restart, verification procedure, persistence across updates, and any limitations. Updating the host CA store alone is not proof that every embedded/custom trust path is fixed.
5. Operational impact and rollback: For a panel-only restart, a v1 update, and v1-to-v2 migration respectively, will the procedure restart Docker or application containers, replace Compose/OpenResty, modify firewall/NAT rules, change website/PHP configuration, or migrate the panel database? Please provide prerequisites, the final fixed version, expected downtime, consistent backup requirements and rollback steps. Existing single-instance PHP and static sites must remain available, so we need to evaluate compatibility and schedule any disruptive step in advance.

Please respond, where possible, with: affected feature/build; fixed version or supported mitigation; supporting evidence; restart/downtime impact; verification and rollback steps. This request is for clarification and a plan only, not authorization to access or modify any server.

References

• Mozilla incident 2083449
• Go vulnerability GO-2026-6809
• Official October 2026 security notice
• 1Panel v2.4.1 release
• Official v1-to-v2 migrator

Thank you.