Modern, complicated PCIe device run large firmware that can, and has, been found to contain vulnerabilities that allow remote exploitation. A vulnerability on the card could allow a remote attacker to gain complete arbitrary code execution on the card and modify the behavior of its firmware. So let's assume that an attacker has found a vulnerability in your WWAN card and has successfully gained code execution privileges on the card itself. What can they do with this?
DMA attacks
When a PCIe device is present, the operating system will configure it and will usually set the bus master enable bit, a feature that allows it to perform arbitrary DMA requests (reads and writes to any memory location). Operating systems do have a way to prevent this when a modern processor is used. A processor's IOMMU is capable of filtering out DMA requests to unusual locations. When an IOMMU is properly supported and enabled, the operating system kernel will set up a small quarantine area where DMA is allowed. The PCIe device and the kernel communicate by passing data in that dedicated region. If the device attempts to write anywhere else, the IOMMU will block it.
Mitigating this is rather simple, luckily. All you have to do is ensure that the IOMMU is enabled and set to enforce. This requires the BIOS contain DMAR translation tables, a component of ACPI which tells the IOMMU what memory regions will be dedicated for DMA for which devices. On some systems, especially certain laptops, the DMAR tables can be corrupt, making it impossible to enable protections. For this reason, some Linux distributions disable the IOMMU by default. You will have to enable it by setting the intel_iommu=on
or amd_iommu=force
boot parameters.
Kernel driver exploits
If an IOMMU is present and enabled, the device and kernel will only be able to communicate using a dedicated region of memory where DMA writes and reads are permitted. The device will pass data structures to the kernel and will then tell the kernel to process the data by issuing an interrupt or the related MSI. When this signal is raised, the kernel will call an interrupt handler to process the data at the designated DMA buffer. With this comes the risk that this processing stage itself is buggy. Code in the kernel runs at ring 0, the most privileged protection ring, so any vulnerability in its code can be disastrous. In the case where a vulnerability can be triggered by placing malicious data in the DMA buffer and raising an interrupt, then even an IOMMU will not be able to protect you.
It is more difficult to protect from bugs in kernel drivers. It would be necessary to understand the attack surface area provided by the specific WWAN driver you will be using. This requires digging through the kernel source code. In most cases, this is more trouble than it is worth. If you cannot do that, then it may be possible to use a hypervisor like Xen to virtualize the kernel driver. This is the technique used by Qubes OS, an operating system which provides heavy hypervisor-based isolation to each hardware component. When an isolation technique like that it used, a kernel driver vulnerability's impact will be limited to that of compromising the VM used for networking isolation.
Network abuse
A WWAN device is naturally going to behave as your NIC, receiving and sending packets to the network. An oft-overlooked problem with a vulnerable NIC is the fact that any attacker that has compromised it will now be in a privileged position on the network. They will be able to modify any incoming or outgoing packets at will and can perform man-in-the-middle attacks easily. A simple attack vector would be to replace a downloaded update or executable with a malicious version. Even without privileged access to memory, a compromised NIC can do a lot of damage.
Protecting against this threat requires the same threat model as protecting against any other MITM attacker on a privileged position on the network, such as a router. Authenticated end-to-end encryption with a local hardware firewall, for example, is enough to largely mitigate any damage that could be done by a compromised NIC attempting to perform a MITM attack. This would ensure that the most malicious action the NIC could take is to degrade performance or deny service.