[Bug]: Bridged Wi-Fi interface is listed but rejected on macOS Apple Silicon

[Angeldevnotes]

Version

7.2.18

Host OS Type

macOS

Host OS name + version

macOS Sequoia 15.7.9

Host Architecture

ARM

Guest OS Type

macOS

Guest Architecture

ARM

Guest OS name + version

No response

Component

Network

What happened?

Environment

• Host: macOS 15.x
• Host architecture: Apple Silicon (ARM64)
• VirtualBox: 7.2.18 ARM64
• Guest OS: Debian 13 ARM64
• Network: Wi-Fi
• Adapter mode: Bridged Adapter

Problem

VirtualBox correctly lists the host Wi-Fi interface with:

VBoxManage list bridgedifs

For example:
Name:            en0: Wi-Fi
Status:          Up
VBoxNetworkName: HostInterfaceNetworking-en0

However, manually configuring the VM with the interface name returned by VirtualBox produces:
VBoxManage modifyvm "VM_NAME" \
  --nic1 bridged \
  --bridgeadapter1 "en0: Wi-Fi"

and VirtualBox reports:
Interface "en0: Wi-Fi" doesn't seem to exist

When starting the VM, it can then fail with:
NetworkAttachmentType_Bridged: FindByName failed
Nonexistent host networking interface, name 'en0: Wi-Fi'

followed by:
NS_ERROR_FAILURE (0x80004005)

The host Wi-Fi interface itself is active and working, and NAT networking works correctly.

### How can we reproduce this?

The problem can be avoided by retrieving the interface name directly from VBoxManage and passing the returned value back to modifyvm:

IFACE=$(VBoxManage list bridgedifs \
  | sed -n 's/^Name:[[:space:]]*//p' \
  | head -1)

VBoxManage modifyvm "VM_NAME" \
  --nic1 bridged \
  --bridgeadapter1 "$IFACE"

With this approach, the VM starts successfully using Bridged networking over Wi-Fi.
A complete workaround is documented here:

https://github.com/Angeldevnotes/VirtualBox-macOS-Apple-Silicon-Bridged-Wi-Fi-Workaround

Expected behavior
An interface reported by:
VBoxManage list bridgedifs

should be accepted when the same interface is supplied to:
VBoxManage modifyvm --bridgeadapter1

Actual behavior
The interface is listed by VirtualBox but may be rejected when supplied to modifyvm, resulting in a non-existent host networking interface error.
Additional information
The issue was reproduced on Apple Silicon with the ARM64 build of VirtualBox.
I am not sure whether this is related to interface-name resolution on macOS/ARM64, so I am reporting the observed behavior and workaround rather than assuming the root cause.

### Did you upload *all* of your necessary log files, screenshots, etc.?

- [x] Yes, I've uploaded all pertinent files to this issue.