While I can see VirtualBox support is a niche especially in Fedora,
there appears to be a bug with how Virtual Box driver of libvirt
deals with libvirt's own native data structures, observe:

(gdb) bt             
#0  0x00007f0d0ae227eb in vboxDumpSharedFolders (machine=<optimized out>, data=0x7f0d1c001d60, def=0x7f0d200140a0) at ../../src/vbox/vbox_common.c:36
30
#1  vboxDomainGetXMLDesc (dom=<optimized out>, flags=<optimized out>) at ../../src/vbox/vbox_common.c:4128
#2  0x00007f0d2f142146 in virDomainGetXMLDesc () at /lib64/libvirt.so.0
#3  0x0000560a4e76e1f8 in remoteDispatchDomainGetXMLDesc (server=0x560a50682df0, msg=0x560a50725330, ret=0x7f0d20000b80, args=0x7f0d20015550, rerr=0x
7f0d2c975960, client=<optimized out>) at ./remote/remote_daemon_dispatch_stubs.h:7077
#4  remoteDispatchDomainGetXMLDescHelper (server=0x560a50682df0, client=<optimized out>, msg=0x560a50725330, rerr=0x7f0d2c975960, args=0x7f0d20015550
, ret=0x7f0d20000b80) at ./remote/remote_daemon_dispatch_stubs.h:7054
#5  0x00007f0d2f065a70 in virNetServerProgramDispatch () at /lib64/libvirt.so.0
#6  0x00007f0d2f06ab58 in virNetServerHandleJob () at /lib64/libvirt.so.0
#7  0x00007f0d2ef7a772 in virThreadPoolWorker () at /lib64/libvirt.so.0
#8  0x00007f0d2ef79cf9 in virThreadHelper () at /lib64/libvirt.so.0
#9  0x00007f0d2ec00479 in start_thread (arg=0x7f0d2c976680) at pthread_create.c:462
#10 0x00007f0d2eb12b53 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

/usr/src/debug/libvirt-6.4.0-1.fc33.x86_64/src/vbox/vbox_common.c:

3628│         gVBoxAPI.UISharedFolder.GetHostPath(sharedFolder, &hostPathUtf16);
3629│         VBOX_UTF16_TO_UTF8(hostPathUtf16, &hostPath);
3630├>        def->fss[i]->src->path = g_strdup(hostPath);
3631│         VBOX_UTF8_FREE(hostPath);
3632│         VBOX_UTF16_FREE(hostPathUtf16);

(gdb) p def->fss[i]->src 
$1 = (virStorageSourcePtr) 0x0

(gdb) ptype def->fss[i]->src
type = struct _virStorageSource {
    virObject parent;
    unsigned int id;
    int type;
    char *path;
    int protocol;
    char *volume;
    char *snapshot;
    char *configFile;
    char *query;
    size_t nhosts;
    virStorageNetHostDefPtr hosts;
    size_t ncookies;
    virStorageNetCookieDefPtr *cookies;
    virStorageSourcePoolDefPtr srcpool;
    virStorageAuthDefPtr auth;
    virStorageEncryptionPtr encryption;
    virStoragePRDefPtr pr;
    virTristateBool sslverify;
    unsigned long long readahead;
    unsigned long long timeout;
    virStorageSourceNVMeDefPtr nvme;
    virStorageSourceInitiatorDef initiator;
    virObjectPtr privateData;
    int format;
    virBitmapPtr features;
    char *compat;
    _Bool nocow;
    _Bool sparse;
    virStorageSourceSlicePtr sliceStorage;
    virStoragePermsPtr perms;
    virStorageTimestampsPtr timestamps;
    unsigned long long capacity;
    unsigned long long allocation;
    unsigned long long physical;
    _Bool has_allocation;
    size_t nseclabels;
    virSecurityDeviceLabelDefPtr *seclabels;
    _Bool readonly;
    _Bool shared;
    virStorageSourcePtr backingStore;
    virStorageDriverDataPtr drv;
    char *relPath;
    char *backingStoreRaw;
    virStorageFileFormat backingStoreRawFormat;
    char *nodeformat;
    char *nodestorage;
    int haveTLS;
    _Bool tlsFromConfig;
    char *tlsAlias;
    char *tlsCertdir;
    _Bool detected;
    unsigned int debugLevel;
    _Bool debug;
    int iomode;
    int cachemode;
    int discard;
    int detect_zeroes;
    _Bool floppyimg;
    _Bool hostcdrom;
    char *ssh_user;
    _Bool ssh_host_key_check_disabled;
} *

Might be a fallout after some generalization from mere paths?

Nonetheless, it doesn't appear to involve VirtualBox API as such,
that's why I dare to raise it here :-)

$ rpm -qf /usr/sbin/libvirtd \
  /usr/lib64/libvirt/connection-driver/libvirt_driver_vbox.so
> libvirt-daemon-6.4.0-1.fc33.x86_64
> libvirt-daemon-driver-vbox-6.4.0-1.fc33.x86_64