{"id":"7138dca1-0eb6-4cd1-b53c-9ebb52c491cd","arxiv_id":"2510.22024","paper_version":3,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Tesla Model 3 and Cybertruck telematics units are susceptible to IMSI catching, rogue-base-station attachment, deterministic attach loops without fallback, and silent acceptance of SMS and emergency broadcasts.","lead":"This paper built a fake LTE tower inside a shielded tent and showed that Tesla Model 3 and Cybertruck telematics units will reveal subscriber identifiers, camp on rogue networks, loop in failed attach states, and accept SMS and emergency alerts invisibly. It matters because regulators are trying to certify that connected cars have secure, resilient, transparent cellular links — and this case study gives concrete evidence that they inherit decades-old mobile-network weaknesses","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Fallback/no-fallback results are confounded: the authors disabled the eSIM via Tesla Toolbox for pSIM tests, so the observed 'no fallback to eSIM' is a setup artifact, not a production vehicle property.","rationale":"The reader's weakest assumption focuses on lab-to-field transfer of the custom testbed, which is a valid general concern. My concern is more specific and internal: the fallback experiments disabled the eSIM via Tesla Toolbox, so the headline 'no fallback to eSIM' is a direct consequence of the experimental configuration, not a discovered vehicle behavior. The reader's assumption about 'SIM credentials the authors programmed' is related but does not identify this particular confound; hence partial agreement. This concern is load-bearing because the abstract and regulatory discussion explicitly cite insecure fallback as a key result. The other findings—IMSI catching, FBS partial attach, silent acceptance of SMS/ETWS—are less affected, so the paper still has value as a case study, but the fallback claim needs either a corrected experiment with eSIM enabled or a clear reframing as a single-SIM limitation. I therefore keep the reader's CONDITIONAL verdict unchanged: the paper should be accepted only if this confound is addressed by retesting or by substantially weakening the fallback claim.","tokens_in":24049,"tokens_out":7680,"duration_ms":76843,"concrete_test":"Repeat the NAS-rejection and partial-attach experiments of §5 (Table 3) on a Tesla with the factory eSIM profile left enabled and no Toolbox modifications, using a carrier-sanctioned test core (or a second programmable SIM with valid credentials in the physical slot while eSIM remains active). If the TCU then falls back to the eSIM (or to WiFi) after repeated NAS rejections, the reported no-fallback behavior is an experimental artifact; if it still loops and camps indefinitely, the claim stands. Also record whether the TCU can even select a pSIM while eSIM is enabled, as the paper says eSIM is prioritized.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim that Tesla's TCU lacks fallback to eSIM/WiFi (Abstract; Table 3; §5 'Fallback and Partial States Flaws') is not supported by the experiments as reported. Appendix B.V states that to use the physical SIM, the authors 'explicitly disabled eSIM functionality' through Tesla Toolbox, forcing the vehicle to use the pSIM, and that by default Tesla prioritizes the eSIM over the physical SIM slot. The fallback experiments (control-plane rejections, PDN failures, routing blackholes) were all run in this configuration ('All tests used our previously validated custom network with T-Mobile PLMN'), i.e., with the eSIM switched off. Observing that the TCU does not 'switch to the eSIM profile' when the pSIM fails is therefore a tautology: the alternative was disabled by the experimenter. In the factory configuration, the eSIM is the primary, not a fallback, so the relevant failure case is 'the only SIM fails and no other SIM is available,' which is a single-SIM limitation, not a Tesla-specific fallback flaw. Since the FBS and partial-attach tests (§5, Table 2, Figure 5) used the same pSIM-only setup, the claimed DoS blocking backend services is also confounded by the disabled eSIM. This directly undermines the 'insecure fallback mechanisms' headline and the R155/R156 conclusions about lack of recovery. The IMSI catching and silent-SMS observations are less affected, but the availability/fallback pillar of the paper's contribution is load-bearing and currently rests on an experimental configuration that real adversaries cannot create.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a black-box LTE security evaluation of Tesla Model 3 and Cybertruck telematics units, conducted inside a 93 dB shielded enclosure using Amarisoft and srsRAN LTE stacks, programmable SIMs, and Tesla diagnostic interfaces (Toolbox/Service Mode). The authors report that the TCU discloses IMSI/GUTI when a rogue eNodeB broadcasts a matching PLMN, attaches partially to rogue cells and fails to recover, shows no fallback to eSIM/WiFi under control-plane, PDN, and routing failures, and silently accepts SMS and ETWS/CMAS messages without user-facing alerts. The paper maps these findings to UN R155/R156 and proposes mitigations such as stricter PLMN whitelisting, disablement of legacy ciphers/SMS, and better fallback logic.","tokens_in":24270,"tokens_out":6594,"duration_ms":72449,"significance":"If the headline findings are supported, this is a valuable early controlled study of automotive TCU behavior against known LTE attacks: the empirical setup is credible, with two independent LTE stacks, reference-device validation, 10 trials per configuration, direct TCU state observation, and a clear non-invasive methodology. The disclosure to Tesla and use of Consumer Reports vehicles with consent are also positive features. However, the paper's contribution is in large part a transfer of known LTE attacks to a vehicular context, and its strongest availability/fallback and silent-SMS claims are not fully supported by the reported experiments. With re-scoping and additional controls, the study could serve as a useful case study for the automotive cellular-security community.","major_comments":[{"comment":"The no-fallback-to-eSIM result is a setup artifact. Appendix B.V states that after inserting the custom SIM, the authors 'explicitly disabled eSIM functionality' through Tesla Toolbox, and Appendix B.I notes the default eSIM is prioritized. Table 3 then reports 'Fallback triggered: No' across control-plane, PDN, and routing failures, and §5 states the TCU never switched to the eSIM profile. Observing no eSIM fallback after the experimenter disabled the eSIM is tautological. The FBS and partial-attach tests (Table 2, Figure 5) used the same pSIM-only configuration, so the claimed DoS 'blocking backend services' also does not test the production eSIM-primary configuration. The abstract's 'insecure fallback mechanisms' and the R156 recovery/user-awareness mapping are therefore not established as reported. The WiFi-fallback part may be non-tautological, but Table 3 aggregates eSIM and WiFi i","section":"Appendix B.V; Table 3; §5 'Fallback and Partial States Flaws'"},{"comment":"The abstract claims 'silent SMS injection' and 'broadcast message spoofing without driver awareness,' but the experiments show protocol-level delivery of well-formed text SMS over IMS and absence of UI display, not injection of silent/binary SMS or any demonstrable system-side effect. The paper concedes the silence 'may be intentional' and does not show that the TCU processed the ETWS/CMAS content beyond base-station acknowledgment. As a security claim, this is a UI-transparency observation with latent risk, not a demonstrated vulnerability. Please align the abstract and §5 terminology with the actual evidence, and either provide evidence of a concrete processing path or clearly label this as an unverified latent risk.","section":"Abstract; §5 'SMS and Emergency Issues'"},{"comment":"The paper states that the experiments 'reveal several violations' of UN R155/R156 and Table 4 maps each observed behavior to a violation. This is too categorical. R155 is risk-based and allows OEMs to manage residual risk through their cybersecurity management system; R156 7.2.2.2 concerns user notification before/after software updates, which were not exercised in any of the reported tests. Observed protocol behaviors can inform risk assessments, but the paper does not show that Tesla's actual OTA process, user-notification flow, or CSMS documentation violates the regulations. Please rephrase the regulatory discussion as 'threats to the security objectives referenced by R155/R156' rather than as demonstrated non-compliance.","section":"§6 'Regulatory Implications'; Table 4"},{"comment":"The quantitative DoS/recovery claims are setup-dependent in a way that should be stated in the main text, not only in a caveat. The observed 'failure to reattach to the legitimate network' occurred while the attacker's cell continued to transmit at high gain; this is an expected consequence of PLMN-priority cell selection when the rogue cell remains dominant, and it does not measure recovery after the attacker disappears. The paper's Figure 5 shows backend failure in the authors' own core with the attacker cell present, but no measurement is reported of how quickly the vehicle returns to service when the rogue cell is removed. The 90–100% attach success and 4-second connection durations are also explicitly acknowledged to depend on the experimental setup. Please separate the robust finding ('TCU attaches to a stronger cell broadcasting a permitted PLMN') from the setup-specific claims ab","section":"Table 2; §5 'False Base Station Susceptibility'"}],"minor_comments":[{"comment":"The table's most important condition is that IMSI/GUTI disclosure occurred only when the rogue eNodeB broadcast a PLMN matching the vehicle's current SIM (310260 or 310150). This should be prominent in the main text, as it tempers the 'lack of effective defenses' wording: the result confirms the known LTE behavior that a UE will answer an identity request from a cell it has selected, not a Tesla-specific weakness.","section":"Table 1"},{"comment":"The paper uses 'silent SMS injection' and 'insecure fallback mechanisms' in the abstract, but the body is more measured ('may be intentional,' 'latent risk'). Please make the abstract match the body's confidence level.","section":"Abstract and terminology"},{"comment":"The traffic captures are hard to interpret without annotations. In particular, Figure 15 should mark which IP addresses are Tesla backend endpoints and which are testbed-local, and Figure 16 should be labeled with the NAS/RRC message names. This would improve reproducibility for readers who cannot access the raw logs.","section":"Figures 5, 15, 16"},{"comment":"The paper says 'The tested vehicles were the Tesla Model 3 and Cybertruck (U.S. region 2024)' but does not give software versions or precise testing dates. Since firmware updates can change behavior, please provide the vehicle firmware versions and testing window, as far as the black-box access allows.","section":"§3 'Vehicles Under Test'"},{"comment":"The generalizability claims for other OEMs rest on the cited modem-supplier disclosure (Qualcomm/Quectel) and on casual inspection of other vehicles, not on comparable testing. This is fine as a hypothesis, but the wording should acknowledge that no equivalent experiments were performed on non-Tesla vehicles.","section":"§6 'Cellular Connectivity in Other Automobiles'"}],"recommendation":"major_revision","confidential_remarks":"The empirical core is solid and the authors should be encouraged to revise. The most important issue is the eSIM-disabling confound in the fallback/FBS experiments; without a control run or a clear re-scoping, the central availability claim is unsupported. The SMS/ETWS and regulatory sections also need rebalancing from 'demonstrated attack/violation' to 'latent risk/potential gap.' If the authors address these, the paper could be a worthwhile case study for the automotive cellular-security literature."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Short version: this is a real empirical contribution—first systematic LTE attack battery against production Tesla Model 3 and Cybertruck TCUs in a controlled, shielded testbed. The IMSI catching and rogue-cell partial attach results look solid. But the headline 'insecure fallback mechanisms' claim has a load-bearing confound that the authors appear to have created themselves.\n\nWhat's new: they integrated a production TCU with Amarisoft and srsRAN, used reference devices to validate the network, ran 10 trials per configuration, and observed TCU behavior directly via Service Mode and Toolbox. The two-stage whitelisting finding—permissive attach, late data-service gating—is genuinely interesting. The deterministic reattachment loops without random backoff are worth reporting, as is silent protocol-level acceptance of SMS and ETWS. These are measurements, not derivations, and the paper is honest about much of its setup.\n\nSoft spots, in proportion:\n\n- The fallback experiments are confounded. Appendix B.V says the eSIM was explicitly disabled via Toolbox for pSIM tests, and that Tesla prioritizes eSIM by default. So 'no fallback to eSIM' is a tautology. The FBS/DoS tests also ran in this pSIM-only configuration, which weakens the availability claims and the R155/R156 mapping built on them. This is fixable: run the same tests with the eSIM enabled and see what happens, or at least reframe the claim as a single-active-SIM limitation rather than a Tesla-specific fallback flaw.\n\n- Most of the attacks are inherited 3GPP protocol behavior, not Tesla-specific bugs. IMSI catching when broadcasting the legitimate PLMN is how LTE works. The paper should say 'this vehicle behaves like a standard UE, which means it inherits standard UE attacks' rather than implying a unique Tesla misconfiguration.\n\n- The silent SMS/ETWS acceptance is shown at the protocol level, but there is no demonstrated consequence inside the TCU. They concede the silence 'may be intentional.' The RCE/DoS speculation is just that.\n\n- The regulatory conclusions outrun the data: two vehicles, one OEM, lab-only, no on-road testing. The authors do include caveats, but the Table 4 mapping reads more confident than the evidence supports.\n\n- Reproducibility: no firmware versions, no released artifacts. That matters for a case study that is otherwise empirically strong.\n\nWho this is for: automotive security people, cellular protocol researchers, and anyone doing R155/R156 compliance work. It deserves a serious referee, but with major revision—especially re-running the fallback tests with the eSIM in its default state and toning down the regulatory claims. I'd take it to reading group as a good case study in how easy it is to confound your own field experiments.","headline":"First systematic LTE attack battery on production Tesla TCUs with credible measurements—but the headline 'insecure fallback' claim is confounded by the authors disabling the eSIM in the very experiments where they report no fallback.","tokens_in":24920,"tokens_out":3119,"would_cite":true,"duration_ms":28514,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper establishes that a wireless-only adversary with a rogue LTE base station can force Tesla vehicles to leak their SIM identity, camp on a fraudulent cell, and silently lose access to backend services, because the telematics unit's","keywords":["LTE security","connected vehicles","IMSI catching","rogue base station","telematics control unit","Tesla","UN R155","OTA updates"],"falsifier":"A controlled drive-by experiment on a live commercial network: a rogue eNodeB advertising the vehicle's actual carrier PLMN at elevated power, with the car moving at speed and the real carrier cell still present. If the TCU either stays on the legitimate cell, or falls back to eSIM/WiFi within a few seconds of the rogue attach, the paper's DoS and fallback conclusions do not transfer to real driving conditions.","tokens_in":23756,"feed_emoji":"📡","tokens_out":5722,"duration_ms":51981,"temperature":0.7,"pith_summary":"This paper tries to establish that the LTE connectivity stack in current Tesla vehicles has the same known cellular weaknesses as smartphones, but with worse consequences because vehicles are always-on, black-box, and without user-facing network controls. Using a shielded RF testbed with production Model 3 and Cybertruck, the authors show that a wireless-only attacker who spoofs the vehicle's real carrier identity can obtain the SIM's IMSI/GUTI, lure the vehicle onto a rogue cell, and leave it in a partial-attach state that blocks backend services such as OTA updates. They also show the vehicle enters deterministic reattachment loops under control-plane rejections, never falling back to eSIM or WiFi, and that SMS and emergency broadcast messages are processed silently without any driver-visible alert. If correct, the findings mean a single attacker with modest equipment can degrade safety-relevant connectivity and privacy for vehicles that regulators (UN R155/R156, ISO/SAE 21434) assume to be secure and resilient. The paper's own stated limitations — no on-road testing, testbed-dependent timing, and the need to spoof the legitimate PLMN — bound how far the results transfer to live adversarial conditions.","feed_headline":"Fake LTE cell hijacks Tesla link, blocks OTA updates","feed_subtitle":"Black-box tests show Tesla's telematics unit leaks its SIM identity, camps on rogue cells, and never falls back to WiFi.","key_machinery":"The central object is the telematics control unit's LTE network-selection and attach state machine — the logic that decides which cell to camp on, how to answer NAS identity requests, when to retry attach, and when to fall back to WiFi or an alternate SIM profile. The argument turns on a two-stage whitelist: at the radio/attach stage the TCU accepts any PLMN, including test identifiers, while a backend 'roaming' gate filters data services only after attach and PDN setup, too late to stop control-plane attacks. The paper also relies on the modem's advertised capability set (support for GSM, legacy ciphers, null ciphering, silent SMS paths) as evidence of an enlarged attack surface.","core_discovery":"The paper reports that a production Tesla's LTE connectivity behaves like an unusually permissive mobile device: it answers unprotected identity requests from a rogue base station that broadcasts the vehicle's real carrier PLMN, disclosing both IMSI and GUTI; it attaches to a spoofed cell even when the attacker cannot complete authentication, camping there with only partial connectivity; and under NAS rejections or data-plane blackouts it neither switches to the eSIM profile nor to WiFi, instead entering deterministic reattachment loops or indefinite partial states. It further reports that the TCU advertises legacy GSM/GPRS capabilities and null ciphering (while correctly rejecting null inte","pith_inferences":["Editorial inference: The attack's practical reach may be narrower than the headline suggests — real-world cell selection with vehicles in motion and operator-side defenses could break the PLMN-matching requirement; a reasonable next test is a drive-by experiment against a live carrier.","Editorial inference: The absence of any UI alert for SMS/ETWS may be a deliberate product decision (e.g., alerts routed to the phone app), so the security question is whether any hidden handler exists; exposing TCU logging would settle it.","Editorial inference: If regulators adopt the paper's mapping, type-approval audits may start requiring evidence of fallback behavior, not just protocol conformance.","Editorial inference: A direct comparison with current smartphones under the same testbed would isolate vehicle-specific failures from generic LTE weaknesses; the paper did not run that comparison."],"forward_implications":["A wireless-only attacker with a software-defined radio can provoke identity disclosure and persistent denial of service without any code execution, simply by spoofing the vehicle's carrier PLMN.","Vehicles can be parked in a partial-attach state where backend services go dark, with no fallback to eSIM or WiFi and no driver alert, blocking OTA updates and remote commands.","The same telematics behavior implies compliance gaps against UN R155/R156 and ISO/SAE 21434, particularly around OTA availability, user awareness, and DoS resilience.","Because the modem and baseband stack are third-party components, the exposure is likely shared by other OEMs using the same hardware.","Silent acceptance of SMS and emergency broadcasts means injected messages can act on the vehicle without any trace visible to the driver."],"fun_headline_variants":["Tesla LTE leaks IMSI and camps on rogue cells","Rogue base station hijacks Tesla telematics, blocks OTA","Tesla cars vulnerable to IMSI catching and SMS spoofing","Tesla LTE never falls back to WiFi under attack","Fake cell tower silences Tesla OTA updates"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The headline results assume that behavior observed in a shielded testbed with SIM credentials the researchers themselves programmed — including the requirement that the rogue cell broadcast the vehicle's genuine carrier PLMN — is what a real adversary would encounter against live commercial networks.","fun_headline_variants_meta":{"raw":{"variants":["Tesla LTE leaks IMSI and camps on rogue cells","Rogue base station hijacks Tesla telematics, blocks OTA","Tesla cars vulnerable to IMSI catching and SMS spoofing","Tesla LTE never falls back to WiFi under attack","Fake cell tower silences Tesla OTA updates"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000676,"raw_usage":{"total_tokens":2885,"prompt_tokens":691,"completion_tokens":2194,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":435,"completion_tokens_details":{"reasoning_tokens":2123}},"tokens_in":435,"tokens_out":2194,"duration_ms":13424,"temperature":1.0,"reasoning_tokens":2123,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T08:11:03.794826+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"A controlled drive-by experiment on a live commercial network: a rogue eNodeB advertising the vehicle's actual carrier PLMN at elevated power, with the car moving at speed and the real carrier cell still present. If the TCU either stays on the legitimate cell, or falls back to eSIM/WiFi within a few seconds of the rogue attach, the paper's DoS and fallback conclusions do not transfer to real driving conditions.","supporting_citations":[],"review_version":1}