PaperlayerView exact revision on arXiv

Source-linked AI summary

Lights, Camera, Attack: Exploiting Temporal HDR Fusion with Pulsed Light

Alkim Domeke, Michael Kuhr, Roman Gilliatt, Mohammad Hamad, Sebastian Steinhorst, Bing Li, Long Cheng, Mert D. Pesé

arXiv:2609.37742v1cs.CR

TL;DR

Temporal HDR fusion assumes illumination remains sufficiently consistent across sequential exposures, but prior work had not formulated deliberate cross-exposure inconsistency as a physical attack on that fusion process. This paper introduces FLASH, an external pulsed-light attack, and reports pipeline-dependent failures including extreme darkening on tested cameras.

  • Problem

    Prior work documented temporal illumination variation degrading HDR but had not formulated deliberate cross-exposure inconsistency as a physical attack on temporal multi-exposure fusion.

    Source: §1 · p. 2

  • Method

    FLASH uses external pulsed light to create inconsistent illumination across sequential HDR exposures before downstream perception, without camera access, raw brackets, fusion-algorithm knowledge, or exact phase synchronization.

    Source: §1 · p. 2

  • Results

    50.0% of iPhone 16 Pro frames and 33.7% of Wyze Battery Cam Pro frames showed extreme darkening relative to continuous-light controls.

    Source: §1 · p. 2

  • Takeaways & Limitations

    The findings identify temporal HDR fusion itself as a physical attack surface and call for validating cross-exposure consistency before accepting exposure evidence for fusion.

    Source: §9 · pp. 13–14

    Independent radar or LiDAR may preserve evidence and reduce risk, but vehicle-level risk depends on sensor coverage, fusion architecture, modality weighting, and failure handling.

    Source: §8 · p. 13

Abstract

from arXiv · show

Modern cameras widely use temporal High Dynamic Range (HDR) to improve visibility by capturing a sequence of exposures with different integration times and fusing them into a single image. This process implicitly assumes that scene illumination remains sufficiently stable during capture. We introduce FLASH (Fusion-Level Attack by Saturating HDR), an external pulsed-light attack that deliberately attacks this assumption by creating cross-exposure inconsistency before downstream perception. FLASH exploits an algorithmic assumption rather than relying on sensor damage or hardware failure, and requires neither physical camera access, access to raw exposure brackets, knowledge of the fusion algorithm, nor exact phase lock to the camera. Across eight physical camera platforms spanning embedded, surveillance, photography, smartphone, and automotive use cases, and matched optical controls, FLASH causes pipeline-dependent darkening, overexposure, and visibility loss. This includes extreme-darkening rates of 50.0% on an iPhone 16 Pro and 33.7% on a Wyze Battery Cam Pro. On the Wyze camera, FLASH triggers the system-level low-visibility response in 10/10 trials, compared with 0/10 continuous-light and randomized-frequency flashing controls. In a controlled stationary OpenPilot case study, 23.0% of frames exhibit severe darkening in the traffic-cone target region, with target-background CNR decreasing by up to 90.8%. Under FLASH, the OpenPilot interface also fails to display the system-level path state observed in the corresponding control trials. In a controlled night-only HDR reconstruction stress test, a proof-of-concept exposure-rejection defense reduces median output-brightness deviation by 79.16%. These results show that temporal HDR fusion itself requires security-aware validation of exposure evidence.

1 Introduction

Temporal HDR fusion assumes illumination remains consistent across sequential exposures, an assumption FLASH deliberately violates with external pulsed light. Physical tests show pipeline-dependent visibility failures, and a controlled reconstruction test evaluates exposure rejection as a defense.

1 Introduction

  • Temporal HDR combines differently timed exposures, relying on sufficiently consistent scene illumination as the camera ISP aligns and fuses them.Shorter exposures preserve bright-region information, while longer exposures collect more light from darker regions.Source: §1 · pp. 1–2
  • FLASH uses external pulsed light to create cross-exposure inconsistency before downstream perception, without camera access, raw brackets, fusion-algorithm knowledge, or exact phase synchronization.It targets sequential temporal HDR rather than spatial or single-shot HDR architectures.Source: §1 · p. 2
  • 50.0% of iPhone 16 Pro frames and 33.7% of Wyze Battery Cam Pro frames showed extreme darkening relative to continuous-light controls.On Wyze, FLASH triggered the low-visibility response in 10/10 trials, versus 0/10 for continuous-light and randomized-frequency flashing controls; in the stationary comma 3X case study, 23.0% of frames had severe target-region darkening and target-background separability decreased by up to 90.8%.Source: §1 · p. 2
  • In a controlled three-exposure night-only reconstruction test, exposure rejection detected corrupted exposures in 756/756 cases and reduced median absolute luma deviation by 79.16%.The clean false rejection rate was 0.0%; the test used a controllable reconstruction pipeline, not proprietary commercial ISP firmware.Source: §1 · p. 2
  • Across camera pipelines, FLASH produces different failures, including frame-level collapse, brightening, exposure compensation, glare, and local visibility degradation.The evaluation spans embedded, surveillance, consumer, and smartphone camera pipelines, plus a controlled stationary comma 3X/OpenPilot case study.Source: §1 · p. 2

2 Background

Temporal HDR extends scene dynamic range by combining observations made with different integration times. Its sequential capture assumes illumination is sufficiently consistent across exposures.

2 Background

  • Temporal HDR cameras combine multiple observations of the same scene, captured at different integration times, into one image.Shorter exposures preserve highlights, while longer exposures preserve shadow detail.Source: §2 · p. 3
  • Temporal HDR fusion assumes consistent illumination across bracketed exposures, but flashing and rapid lighting changes can degrade fusion quality.Abrupt pulsed light may inject substantially more light into one or more exposures, particularly those with longer integration times, creating cross-bracket inconsistency and potentially darkened output.Source: §2 · p. 3
  • HDR controls vary by device, and disabling HDR can reduce visibility in low-light, backlit, and high-contrast scenes.Consumer cameras may not expose HDR as a setting, surveillance cameras may place it in administrative interfaces, and automotive systems may manage it through sensor or ISP configurations.Source: §2 · p. 3

3 Related Work

Prior work documents optical attacks and illumination-driven HDR failures, but does not formulate deliberate cross-exposure inconsistency as an attack on temporal fusion. FLASH targets that fusion assumption rather than sensor saturation, rolling-shutter readout, or downstream-model optimization.

3 Related Work

  • Continuous strong-light attacks cause broad frame-level overexposure, while spatial optical attacks place structured perturbations in selected scene or image regions.These approaches primarily target sensor capture or downstream perception rather than inconsistent exposure evidence inside temporal HDR fusion.Source: §3 · p. 3
  • Rolling-shutter and scene-wide flashing attacks exploit temporal capture properties, but FLASH specifically creates unequal optical contamination across HDR exposure observations.Other documented HDR failures include motion-induced ghosting and tone-mapping halos or posterization; spatial HDR architectures that capture dynamic-range information concurrently are outside this work's scope.Source: §3 · p. 3
  • Prior work establishes that temporal illumination variation can degrade HDR, but does not formulate deliberate cross-exposure inconsistency as a physical attack on temporal multi-exposure fusion.FLASH targets the fusion assumption inside the camera ISP rather than persistent sensor saturation, rolling-shutter readout, or optimization against a downstream perception model.Source: §3 · p. 3

4 Threat Model

The threat model is a temporal HDR camera whose ISP fuses multiple exposures. FLASH uses an external pulsed-light source to create unequal illumination across them, subject to optical and timing constraints.

4 Threat Model

  • The victim camera captures n ≥2 exposures with different integration times and combines them through an ISP fusion and tone-mapping pipeline.FLASH injects pulsed light so one or more exposures receive unequal illumination; the resulting inconsistency can produce darkened, overexposed, clipped, or distorted output.Source: §4 · pp. 3–4
  • FLASH requires line of sight and sufficient received illumination to contaminate exposure observations unequally.Feasibility depends on source strength, distance, aiming angle, relative height, ambient illumination, and temporal pulse overlap; the pulse train must overlap the exposure sequence unevenly enough to create inconsistency.Source: §4 · p. 4
  • The attacker controls only an external pulsed-light source and can approximately position and aim it; the attack is non-contact, open-loop, and black-box.It does not require camera or host access, RAW buffers, exposure registers, ISP settings or firmware, internal telemetry, or downstream-model access; exact exposure timing, fusion-algorithm knowledge, and phase synchronization are not assumed.Source: §4 · p. 4
  • The evaluation covers controlled simulation, physical black-box camera experiments, and a stationary outdoor comma 3X/OpenPilot case study.These are settings for the same external pulsed-light mechanism, not distinct attack mechanisms.Source: §4 · p. 4

5 FLASH Attack Design

FLASH attacks sequential temporal HDR by directing periodic bright pulses at cameras, creating unequal illumination across exposures that can distort the fused output. Its design separates attacker-selected source settings from camera and environmental conditions, then models how pulse timing overlaps exposure windows.

5.1 Overview

  • Unequal pulse energy across exposures can make temporal HDR fusion produce darkening, overexposure, or visibility loss.FLASH targets cameras that fuse at least two observations captured with different integration times; longer windows generally offer more opportunity for pulse overlap, but no specific exposure must be corrupted.Source: §5.1 · p. 4
  • FLASH does not require the attacker to know the exposure schedule, sensor readout, ISP, or fusion algorithm.The affected exposure subset depends on the exposure schedule, pulse width and frequency, and relative phase.Source: §5.1 · p. 5

5.2 Attack Parameters

  • The design separates attacker-selected settings a = [zf, dfc, θ, Pf, fflash] from operating conditions s = [zc, A, ffps].Figure 2 locates the source and camera and defines the yaw angle; θ = 0° means the flashlight points directly at the camera.Source: §5.2 · p. 5, Figure 2 · p. 5
  • For exposure b, Wk,b spans from tk + δb to tk + δb + Tb, capturing its start time, offset, and integration duration.The injected pulse train and exposure-window timing determine how much flash energy overlaps each exposure.Source: §5.2 · p. 6
  • FLASH seeks unequal pulse overlap across exposures, but evaluates feasible parameter sweeps rather than solving a white-box optimization problem.The fusion pipeline, exposure offsets, exact durations, and number of observations are generally unavailable; a nominal cadence relationship does not guarantee selective overlap.Source: §5.2 · p. 6

6 Experiments

The experiments evaluate FLASH through simulation, matched-control tests on black-box camera pipelines, and a controlled stationary comma 3X/OpenPilot case study. Results span darkening, brightening, and localized visibility loss, with responses varying by pipeline and conditions.

6 Experiments

  • The evaluation uses simulation, seven black-box physical cameras with matched clean, continuous-light, randomized-frequency, and FLASH conditions, and a stationary comma 3X/OpenPilot case study.The component-level physical default is 2 W at 2 m; the system case study uses 2 W at 3 m.Source: §6 · p. 6, §6.1 · pp. 6–7, §6.3.1 · p. 7

6.2 Simulation-Based Evaluation

  • At night, simulated degradation increases from −15.08% at 2 W to −80.20% at 20 W and reaches −54.57% at 1.5 m source height.Spatial sweeps find the strongest response at short range and near-axis aiming; nighttime failures are stronger, while daytime results remain below about 8% at the closest settings.Source: §6.2 · p. 7

6.3.1 Evaluation Design and Cross-Device Comparison

  • 50.0% of iPhone 16 Pro frames show severe and extreme darkening relative to continuous light; Wyze shows 33.7% for both rates, with 10/10 low-visibility responses versus 0/10 controls.Table 4 summarizes control-normalized full-frame responses; other pipelines show different response types rather than uniform darkening.Source: Table 4 · p. 9, §6.3.2 · p. 9, §6.3.1 · p. 9

6.3.2 Dark-Collapse and Timing-Sensitive Responses

  • The iPhone 16 Pro’s extreme-darkening rate is 50.0% versus continuous light and 24.9% versus randomized flashing; Wyze’s rates are 33.7% and 33.5%, respectively.Wyze’s decoded median luma falls below the clean low-light baseline under FLASH, while both controls raise it.Source: §6.3.2 · p. 9, Figure 6 · p. 9

6.3.3 Brightening, Compensation, and Localized Responses

  • The Raspberry Pi AI Camera brightens, the Kodak PixPro FZ45 primarily brightens, and the onn Indoor Camera shows localized visibility and contrast loss rather than full-frame collapse.On onn, target-background CNR decreases 48.8% relative to continuous light; the Raspberry Pi HQ non-HDR camera also shows severe darkening, so not all darkening is HDR-specific.Source: §6.3.2 · p. 9, §6.3.3 · p. 10

6.3.4 Operational Robustness Evaluation

  • Distance and off-axis aiming attenuate the response on both swept cameras, while increased ambient illuminance strongly suppresses the low-light response.Source setting and frame rate yield non-monotonic, device-dependent results, and luma change remains nonzero at every tested frame rate.Source: §6.3.4 · p. 10

6.4 System Case Study: comma 3X Camera-Stream Degradation and OpenPilot Path State

  • 23.0% of compared frames show severe cone-region darkening, worst-frame target-background CNR loss reaches 90.8%, and OpenPilot displays neither path state seen in controls.The analysis is of exported camera streams; the interface observation does not reveal OpenPilot’s internal perception or planning state.Source: §6.4 · pp. 10–11, Table 6 · p. 11
  • The sign and pedestrian trials show glare, lens flare, and local visibility obstruction rather than target-region darkening, while the road-scene stream contains a dark horizontal band.In the pedestrian trial, the target-region median luma change is +305.3%, with 0.0% severe-darkening or extreme-darkening frames.Source: §6.4 · p. 11

7 Proof-of-Concept Mitigation

The paper tests pre-fusion exposure rejection as a way to reduce FLASH-induced reconstruction deviation, using a controlled three-exposure, night-only stress test. The evaluation is a proof of concept in a controllable pipeline, not proprietary commercial camera firmware.

Controlled evaluation visuals

  • FLASH examples show reduced sign visibility and an obscured cone region, while the in-car view has a dark band and displays neither planned nor blocked path.The figures identify these as representative camera-stream and interface observations during the controlled evaluation.Source: Figure 7 · p. 12, Figure 8 · p. 12

Temporal exposure rejection

  • The filter flags exposures with abnormal luminance deviation against clean or recent reference behavior, then excludes or near-zero-weights the flagged exposure before fusion.The three-exposure implementation rejects at most one exposure and reconstructs from the remaining evidence rather than rejecting the whole frame.Source: §7 · p. 12

Controlled defense evaluation

  • 79.16% relative reduction in median absolute luma deviation, from 60.46% to 12.60%, with 756/756 corrupted long exposures rejected and 0.0% clean false rejection.This result is limited to the evaluated single-corruption setting.Source: Figure 9 · p. 12, §7 · pp. 12–13
  • The test used synthetic short-, medium-, and long-exposure brackets from night EXR scenes, with corruption injected only into the long exposure.Commercial cameras do not expose their internal exposure buffers, so evaluation used a controllable HDR reconstruction pipeline.Source: §7 · pp. 12–13

Scope of the mitigation evaluation

  • The unoptimized Python/OpenCV prototype added 108.85 ms median latency per HDR bracket, and broader exposure configurations and corruption patterns were not evaluated.The method also requires the corrupted exposure to exceed its anomaly threshold and at least one remaining exposure to preserve scene information; abrupt benign lighting changes may trigger rejection and reduce reconstruction quality.Source: §7 · p. 13

8 Discussion and Limitations

The discussion cautions that multimodal sensing may preserve some obstacle evidence but does not guarantee immunity, and that the evaluation establishes camera-stream degradation rather than vehicle-level failure. FLASH and its mitigation results also have bounded deployment and evaluation scope.

Sensor Fusion and Vehicle-Level Safety

  • Radar and LiDAR may preserve pedestrian or obstacle evidence, but camera-dependent semantic information and valid-looking corrupted streams can remain consequential.Vehicle-level risk depends on sensor coverage, fusion architecture, modality weighting, and failure handling.Source: §8 · p. 13
  • The comma 3X evaluation shows exported camera-stream degradation, not failure of object detection, sensor fusion, planning, or vehicle control.Whether radar or LiDAR fusion suppresses or propagates FLASH effects remains for future end-to-end multimodal evaluation.Source: §8 · p. 13

Attack Scope and Evaluation Limitations

  • FLASH targets temporal HDR and assumes non-contact line-of-sight deployment, low-to-moderate ambient lighting, feasible emitter placement, and tested devices and environments.The attack is not expected to transfer directly to single-exposure spatial HDR; commercial cameras were evaluated as black boxes, and the defense was tested in a controllable pipeline.Source: §8 · p. 13

9 Conclusion

The conclusion identifies temporal HDR fusion as a physical attack surface because FLASH creates inconsistent illumination across sequential exposures. The reported camera and reconstruction evaluations show pipeline-dependent degradation and a proof-of-concept mitigation result.

Conclusion

  • FLASH produces pipeline-dependent darkening, overexposure, and local visibility degradation; the iPhone 16 Pro and Wyze Battery Cam Pro have extreme-darkening rates of 50.0% and 33.7%, respectively.In the controlled comma 3X case study, target-background CNR in the traffic-cone region falls by up to 90.8%.Source: §9 · p. 13
  • In a controlled three-exposure night-only HDR stress test, proof-of-concept exposure rejection reduces median absolute output-luma deviation by 79.16%.The conclusion calls for validating cross-exposure consistency before accepting exposure evidence for fusion.Source: §9 · pp. 13–14

Ethical Considerations

The authors state that the work assessed theoretical vulnerabilities and camera-pipeline safety without interfering in real-world traffic or other listed settings.

Ethical Considerations

  • No interference was performed in open traffic, private property, photography sessions, or public roadways; pedestrian examples were recorded with consent and identifying faces concealed.The authors frame the work as theoretical vulnerability assessment and camera-imaging-pipeline safety research.Source: Ethical Considerations · p. 14

Open Science

The authors release experimental code to support reproducibility and further exploration of algorithmic vulnerabilities in ISP pipelines.

Open Science

  • The release includes the complete source code for the experimental framework.It includes the HDR-Lab implementation and the Blender-based physical simulation parameter-optimization environment.Source: Open Science · p. 14
  • HDR-Lab is provided as part of the release for reproducing the paper’s modular HDR experiments.Source: Open Science · p. 14
  • The Blender-based simulation parameter-optimization environment is also included to support further exploration.Source: Open Science · p. 14

A Vulnerability Analysis of the HDR Pipeline

This section models how pulsed illumination can disrupt temporal HDR fusion, describes a modular evaluation framework, and specifies the conditions and metrics used in simulation and physical experiments.

A Vulnerability Analysis of the HDR Pipeline

  • Unequal flash energy across exposures can bias radiance reconstruction or remove saturated brackets, leaving insufficient reliable data and reducing detail or target contrast.Fusion and tone mapping can consequently produce darkened or extreme-darkening frames; exposure-fusion weights can also become unstable when brackets appear inconsistent.Source: A Vulnerability Analysis of the HDR… · pp. 17–18

B HDR-Lab Implementation Details

C Parameter Constraints and Interactions

  • The feasible set applies placement, hardware, and safety constraints, while attack effectiveness is evaluated separately from physical feasibility.The attack’s effectiveness is measured from camera output because exposure windows and relative phase are unavailable to the attacker.Source: C Parameter Constraints and Interactions · p. 18

D Metric Definitions

  • The evaluation uses decoded Rec.709 luma changes and target-background CNR to quantify brightness shifts, darkening rates, and separability.Severe and extreme darkening correspond to at least 50% and 80% luma reductions, respectively.Source: D Metric Definitions · pp. 18–19

E Simulation Environment Details

  • The Blender simulation varies source distance, angle, height, and power under controlled ambient illumination.The physical source powers are not treated as equivalent to the lux measurements used in the physical evaluation.Source: E Simulation Environment Details · p. 19

F Component-Level Physical Setup

  • Physical camera tests use a fixed indoor setup with the camera, target board, and flashlight positioned at controlled distances and heights.The cameras are treated as black-box pipelines, and their final image or video outputs are recorded in the available or default capture mode.Source: F Component-Level Physical Setup · p. 20, Figure 11 · p. 20

G Physical Operational Robustness Details

Physical parameter sweeps show that FLASH responses vary with camera and operating conditions; the accompanying legal discussion describes potential consequences of deliberate optical interference.

G Physical Operational Robustness Details

  • On the iPhone 16 Pro, median ΔY′ falls from +60.60 units at 2 m to +12.62 units at 8 m; on the Raspberry Pi Camera Module 3, it falls from +2.82 to +0.42 units.The response peaks near the optical axis: at 0° versus 30°, median ΔY′ is +60.60 versus +14.66 units on the iPhone and +2.82 versus +0.50 units on the Raspberry Pi camera.Source: G Physical Operational Robustness… · p. 20
  • Source-setting responses are non-monotonic, while increasing ambient illuminance suppresses the low-light response on both tested cameras.Capture mode also shapes the response, which remains measurable across the tested frame rates.Source: G Physical Operational Robustness… · p. 20

H Legal Implications of Blinding Autonomous Vehicle (AV) and Surveillance Cameras

  • The legal discussion identifies potential criminal and civil consequences for deliberate optical interference with vehicle, security, or traffic cameras.It cites federal and state criminal provisions as well as possible claims including negligence, trespass to chattels, vandalism, and damages.Source: H Legal Implications of Blinding… · pp. 20–21

I Publication Disclaimer

  • The publication disclaimer states that references to commercial products do not imply government endorsement and that the authors’ opinions do not necessarily represent the government’s views.Source: I Publication Disclaimer · p. 21
Loading 2609.37742v1…