`annotation_layer.js` has logic to keep input elements in sync. The logic uses `document.getElementsByName` with [a name derived from the PDF](https://github.com/mozilla/pdf.js/blob/10a1db698047e612e8ae3da66d12a6c1ac5597a3/src/core/annotation.js#L407) to retrieve the set of related elements. This query is not namespaced, so if the viewer ever adds a `name` attribute to a checkbox or radio input in the page, then the PDF file can get it changed (without user interaction via the scripting interface). Fortunately, there doesn't appear to be any input/radio element in the default viewer code. A custom viewer can be affected by this bug, however.

I suggest to replace the `document.getElementsByTagName` calls with a function that checks that the elements are created by the `annotation_layer.js` code before returning them. There are several ways to do so, e.g. by adding a custom attribute to each input element.

## Seemingly generic property assignment
This code on its own looks dangerous because it allows the caller to overwrite any property
https://github.com/mozilla/pdf.js/blob/99e442941c16561e8826a925b164d79f4ad51fbf/src/display/annotation_layer.js#L684-L688
Fortunately, it is only called with a fixed key, so only the `value` property can be updated in response to user input events:
https://github.com/mozilla/pdf.js/blob/99e442941c16561e8826a925b164d79f4ad51fbf/src/display/annotation_layer.js#L732-L740

## Unchecking other checkboxes on checkbox state change
https://github.com/mozilla/pdf.js/blob/99e442941c16561e8826a925b164d79f4ad51fbf/src/display/annotation_layer.js#L979-L990

## Updating the abstract state (storage)
https://github.com/mozilla/pdf.js/blob/99e442941c16561e8826a925b164d79f4ad51fbf/src/display/annotation_layer.js#L1061-L1065

## Allowing scripts to uncheck checkbox/radio inputs
The others require user interaction to have any effect; this one allows scripts embedded in the PDF to run logic without user interaction.
https://github.com/mozilla/pdf.js/blob/99e442941c16561e8826a925b164d79f4ad51fbf/src/display/annotation_layer.js#L1073-L1077
*   when creating canvases. The default value is {new DOMCanvasFactory()}.
 * @property {Object | string} [background] - Background to use for the canvas.
 *   Any valid `canvas.fillStyle` can be used: a `DOMString` parsed as CSS
 *   <color> value, a `CanvasGradient` object (a linear or radial gradient) or
 *   a `CanvasPattern` object (a repetitive image). The default value is
 *   'rgb(255,255,255)'.
 * @property {Promise<OptionalContentConfig>} [optionalContentConfigPromise] -
 *   A promise that should resolve with an {@link OptionalContentConfig}
 *   created from `PDFDocumentProxy.getOptionalContentConfig`. If `null`,
 *   the configuration will be fetched automatically with the default visibility
 *   states set.
 */
/**
 * Page getOperatorList parameters.
 *
 * @typedef {Object} GetOperatorListParameters
 * @property {string} [intent] - Rendering intent, can be 'display', 'print',
 *   or 'any'. The default value is 'display'.
 * @property {number} [annotationMode] Controls which annotations are included
 *   in the operatorList, for annotations with appearance-data; the values from
 *   {@link AnnotationMode} should be used. The following values are supported:
 *    - `AnnotationMode.DISABLE`, which disables all annotations.
 *    - `AnnotationMode.ENABLE`, which includes all possible annotations (thus
 *      it also depends on the `intent`-option, see above).
 *    - `AnnotationMode.ENABLE_FORMS`, which excludes annotations that contain
 *      interactive form elements (those will be rendered in the display layer).
 *    - `AnnotationMode.ENABLE_STORAGE`, which includes all possible annotations
 *      (as above) but where interactive form elements are updated with data
 *      from the {@link AnnotationStorage}-instance; useful e.g. for printing.
 *   The default value is `AnnotationMode.ENABLE`.