Vulnerabilities

NLTK versions before 3.9.3 contain a download-integrity flaw (CWE-494) in its downloader module: files fetched via nltk.download() are extracted without any integrity or authenticity verification. An attacker positioned on the network path — through a man-in-the-middle attack or DNS poisoning — can substitute malicious package contents that NLTK then extracts onto the host unvalidated. Successful injection could place attacker-controlled files into the environment, with CVSS v4.0 scoring high impact to confidentiality, integrity, and availability of the target. Any developer, CI pipeline, or data-processing environment that installs NLTK via pip and uses its downloader to fetch packages over a network an attacker can influence is affected. No exploitation has been reported in the wild (EPSS ~0.1%, not in CISA KEV); the issue is documented in a published GitHub security advisory (GHSA-5wp5-5229-5g6q).

Do: Upgrade NLTK to 3.9.3 or later (pip install --upgrade nltk) and ensure CI images, requirements files, and containers are rebuilt against the fixed version. As interim mitigation, avoid running nltk.download() over untrusted or attacker-influenceable networks; instead pre-fetch packages from a trusted source and verify their integrity before extraction. Audit build and data pipelines for runtime calls to the NLTK downloader, since static installs that never download packages are not practically exposed.

CVE-2026-62384 is a new, distinct symlink-based bypass of the path-security sandbox in NLTK's FramenetCorpusReader, defeating the fix released in PR #3581 for the earlier FrameNet path-traversal issue CVE-2026-54292 (GHSA-xh95-f55m-82fw). The guard added by that fix, _reject_unsafe_path_component(), only blocks literal path separators, '..' and Windows drive prefixes and never resolves symlinks, and the affected call sites (frame_by_name(), _lu_file() and doc() in nltk/corpus/reader/framenet.py) then perform a lexical abspath() join and open the result via PathPointer.open() with no required_root check, so a separator-free symlink planted inside a FrameNet corpus subdirectory (e.g. frame/) is followed to any file outside the corpus root. An attacker who can plant a symlink in a corpus directory that the application then reads gains disclosure of the contents of XML files located outside the corpus root, since the file is parsed through XMLCorpusView and its parsed fields (such as the frame definition) are returned to the caller; CVSS 4.0 rates this 8.7 High with a network vector and confidentiality-only impact. Anyone running an unpatched nltk installation from the pip ecosystem whose code loads FrameNet data from a directory an attacker can influence is affected, while deployments that only load trusted, locally controlled NLTK data face little risk. No in-the-wild exploitation is known, the flaw is not in CISA KEV, EPSS gives roughly 0.6% odds of exploitation within 30 days (45th percentile), and a self-contained runnable proof of concept is included in the advisory.

Do: If your applications use FramenetCorpusReader (frame_by_name(), _lu_file(), or doc()), upgrade nltk to the patched release for CVE-2026-62384 once published, since no fixed version number is stated in the available data. Until then, keep FrameNet corpus directories (frame/ and the LU and fulltext subdirectories) writable only by trusted principals, audit them for symlinks pointing outside the corpus root, and treat user-supplied corpus archives as untrusted.

Omnigent (a pip-distributed agent framework) does not validate the 'os_env.cwd' field of uploaded agent bundles, so a bundle author can set the agent's working directory to any host path, such as '/' or '/home/<victim>', with no normalization or boundary check anywhere in the spec pipeline. An authenticated, non-admin user can upload a session-scoped bundle with a malicious cwd; on runners deployed without the 'OMNIGENT_RUNNER_WORKSPACE' environment variable, the runner accepts the attacker-supplied path verbatim, making everything under that path in-bounds for the agent's file and shell tools. The attacker gains arbitrary read and write access to the runner host filesystem plus disclosure of host environment secrets; with 'fork=true' and a cwd set to another user's home directory, the runner copies that tree into the agent-readable workspace. Only Omnigent deployments whose runners realize session-scoped uploaded bundles without 'OMNIGENT_RUNNER_WORKSPACE' set are affected, and any authenticated user can trigger it — no admin scope, user interaction, or shared-agent overwrite is required. No public proof of concept is known, the issue is not in CISA KEV, and EPSS currently estimates a 0.4% probability of exploitation within 30 days; CVSS 3.1 scores it 8.8 (High).

Do: Set 'OMNIGENT_RUNNER_WORKSPACE' on every Omnigent runner — CLI- and host-launched sessions already set it, so audit any other launch paths — because it is the only control that overrides attacker-supplied cwd values. No fixed version is stated in the advisory; until a patched pip release ships, restrict agent-bundle uploads to trusted authenticated users and note that the shared-agent guard proposed for the related GHSA-jrrm-9hc7-2v3h advisory does not address this flaw. Once a fix is released, upgrade and re-verify that runner configurations still set the workspace variable so uploaded bundles no longer control the environment root.

CVE-2026-62676 is a fail-open policy bypass in the shared shell-command parser (policies/builtins/_shell.py) of the Omnigent AI agent harness (omnigent-ai/omnigent v0.1.0), which is supposed to enforce a GitHub repo/branch allowlist and working-directory confinement on agents such as Claude Code, Codex, and Pi. When a gated command contains anything the parser does not recognize — such as interpreter flags (bash -lc), unlisted wrappers (timeout, nice, setsid, stdbuf), command substitution (x=$(...)), or an un-split background operator (true & git push) — the parser emits no operation, the evaluator returns None (abstain), and abstention is treated as ALLOW, letting the command run unconfined. A misaligned or prompt-injected agent can then git push to an attacker-controlled repository or a protected branch (code/secret exfiltration) or escape its workspace via git worktree add or git -C. Only deployments relying on Omnigent's built-in shell, GitHub, and working-directory policies are affected; simple forms like a bare git push or env git push are correctly denied, confirming parser incompleteness rather than allowlist logic errors (CWE-184). No public proof-of-concept or in-the-wild exploitation is known, and EPSS assigns a 0.3% probability of exploitation within 30 days.

Do: Track the omnigent-ai/omnigent repository and upgrade to a patched release when one is published; the suggested fix is to make unrecognized gated commands DENY instead of returning None (fail closed), canonicalize known wrappers, and recurse into sh/bash -c payloads and command substitutions while splitting on shell control operators. Until patched, do not treat the GitHub repo/branch allowlist or working-directory confinement as the sole containment for untrusted or prompt-injected agents, and review agent-initiated git push, worktree add, and workspace-escape activity in logs.

CVE-2026-62675 is an authenticated remote-code-execution flaw (CWE-94) in the Omnigent server/runner: uploaded agent bundles may define server-side Python callable tools, and the bundle validator (validate_agent_bundle) does not reject `tools.<name>.callable` entries even though Python callable tools are intended as a trusted operator-only feature. An authenticated user triggers it by uploading a crafted bundle through the multipart `POST /v1/sessions` endpoint (the same path used by the Web UI's custom-agent flow, or directly via the API/CLI from agent YAML); when the uploaded agent's tool is invoked, the runner imports the attacker-specified dotted Python path (e.g., `subprocess.check_output`) via importlib and calls it, executing an arbitrary local command on the runner machine. A successful attacker gains code execution on the runner host with the runner's privileges, producing high confidentiality, integrity, and availability impact (CVSS 3.1: 8.8 High, AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). Affected are hosted or self-hosted Omnigent deployments that expose session creation to ordinary authenticated users, especially multi-tenant setups with shared or managed runner hosts. No public PoC, KEV listing, or confirmed in-the-wild exploitation is known; EPSS estimates roughly a 0.4% probability of exploitation within 30 days.

Do: Upgrade Omnigent (pip) to a release containing the bundle-validation fix as soon as one is published — no fixed version is stated in the available data, so track the omnigent-ai advisory/repository. Interim mitigations: restrict which authenticated users may upload custom agent bundles, disallow or allowlist `tools.<name>.callable` entries in uploaded bundles (including enforcing the policy-handler allowlist for callable tools), and run runners with least privilege on hosts where multi-user command execution is high impact. Prioritize deployments that expose `POST /v1/sessions` to ordinary users against shared or managed runner hosts, as these are the highest-risk configurations.

Omnigent's full agent bundle upload endpoint, PUT /sessions/{session_id}/agent, lets an authenticated user with edit access to their own session overwrite a shared/template agent, because the route checks only the session edit permission and omits the guard that blocks edits to shared/template agents (those with a null session_id). An attacker exploits this by uploading a replacement bundle that adds a stdio MCP server to the shared agent, even though such agents are exposed as not MCP-editable through the normal edit path. Because stdio MCP servers are launched as local subprocesses by runners, every future session created from the poisoned shared agent executes the attacker-controlled command, giving authenticated remote code execution on runner hosts (CWE-94, CVSS 3.1 score 9.0 Critical). Any Omnigent server deployment (pip-installable) serving multiple authenticated users that relies on shared/template agents is affected; the advisory does not specify affected version numbers. Exploitation is not currently known: there is no public proof of concept, EPSS is 0.3% (27th percentile), and the flaw is not in the CISA KEV catalog.

Do: Apply the advisory's suggested fix by adding the shared/template-agent guard (agent.session_id is null) to the PUT /sessions/{session_id}/agent route, and upgrade to a patched Omnigent release once the vendor publishes one. Until then, restrict the bundle upload endpoint to trusted users and audit existing shared/template agents for unexpected stdio MCP servers whose configured commands would execute on runner hosts.

In ONNX before 1.21.0, the 'save_external_data' function builds the external-data file path from the model's external_data location field and opens it for writing without 'O_NOFOLLOW/O_EXCL', after a non-atomic 'os.path.isfile()' check. A local attacker with write access to the directory where a victim serializes external data can deterministically pre-plant a symlink that is being followed, causing the victim's write to append to any file the victim can write, e.g. ~/.ssh/authorized_keys, cron files, or application configs. Fixed in 1.21.0.

django CMS is an easy-to-use and developer-friendly enterprise content management system powered by Django. Prior to 5.0.9, render_object_structure fails to authorize non-PageContent objects that use PlaceholderRelationField. An active staff user without cms.use_structure or model-level view or change permission can request the //admin/cms/placeholder/object/ /structure/ / endpoint with guessed content_type_id and object_id values. The response discloses placeholder slot names, plugin trees, plugin identifiers, labels, and object existence for frontend-editable objects. The fix applies user_can_view_placeholder_source to the non-PageContent branch while keeping the structure board read-only for view-only users. This issue is fixed in versions 5.0.9.

CVE-2026-71428 is a server-side request forgery in the open-source `unstructured` Python document-partitioning library, where the `url=` parameter of `partition()`, `partition_html()`, and `partition_md()` is fetched with `requests.get()` without any private-IP, loopback, scheme, or redirect validation. An attacker who can control that URL — directly or through downstream ingestion layers such as LangChain's UnstructuredURLLoader, LlamaIndex's UnstructuredReader, or Chainlit — can point it at loopback admin APIs, internal HTTP services, or cloud metadata endpoints, and because the response body is returned as document Element text the SSRF is fully readable; redirect-following (on by default) and DNS rebinding provide bypass paths, and the markdown path also lacks a timeout, enabling slow-loris denial of service. An attacker gains the ability to read internal network responses, including secrets such as cloud credentials from metadata services (CVSS 3.1 9.3 Critical, scope-changed, C:H/I:L). Any deployment of the library from version 0.4.7 (Feb 2023) through the current release line (verified on 0.22.26 and still unfixed on main at commit 199f255) is affected — roughly 219 releases with no validation ever added — especially RAG and agent pipelines that ingest user-supplied URLs. There is no evidence of in-the-wild exploitation (EPSS ~0.3%, not in CISA KEV), and no public PoC is known beyond the reporter's local demonstration.

Do: No fixed release is identified in the available data; monitor the unstructured project and upgrade as soon as a patched version is published. Until then, avoid passing attacker-controlled URLs to partition()/partition_html()/partition_md(), restrict fetched URLs to an allowlist of public hosts (blocking private, loopback and link-local IP ranges, and re-resolving DNS at connect time to prevent rebinding), and consider allow_redirects=False to close the redirect bypass. Teams using LangChain's UnstructuredURLLoader, LlamaIndex's UnstructuredReader, or Chainlit should audit whether end users can control the fetched URL.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the MiMoV2OmniMultiModalProcessor in vllm/transformers_utils/processors/mimo_v2_omni.py passes attacker-controlled image and audio strings through _fetch_image, requests.get, and Image.open instead of MediaConnector, bypassing allowed_media_domains and allowed_local_media_path protections and allowing server-side requests and reads of arbitrary files accessible to the vLLM process. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the /v1/completions/derender and /v1/chat/completions/derender endpoints accept caller-supplied GenerateResponse objects whose generate_responses, choices, token_ids, prompt_logprobs, logprobs.content, top_logprobs, and routed_experts structures are processed by OnlineDerenderer and tokenizer.decode before max_model_len, max_tokens, max_num_seqs, or response-size limits are enforced, allowing an authenticated API client to consume excessive CPU and memory and produce oversized responses. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. Prior to 0.27.0, an integer overflow in blockIdx.x * 2 * d in activation_kernels.cu can cause act_and_mul_kernel to consume another batched user's input, allowing a request processed in the same inference batch to receive a partial or complete copy of another user's inference result. This issue is fixed in version 0.27.0.

vLLM is an inference and serving engine for large language models. From 0.20.2rc0 until 0.26.0, safe_load_prompt_embeds in vllm/renderers/embed_utils.py uses torch.sparse.check_sparse_tensor_invariants, whose process-global save, enable, and restore state can be raced by concurrent prompt_embeds parts submitted to POST /v1/chat/completions through AsyncMultiModalItemTracker.resolve_items, asyncio.gather, and the default executor, allowing an invalid sparse tensor to reach tensor.to_dense despite the CVE-2025-62164 guard when enable_prompt_embeds is enabled. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the structured_outputs.regex parameter in vllm/v1/structured_output/backend_lm_format_enforcer.py is passed to lmformatenforcer.RegexParser without compile_regex_with_timeout or validation in validate_structured_output_request_lm_format_enforcer, allowing an unauthenticated /v1/completions request against the lm-format-enforcer backend to consume a CPU core and stall the structured-output engine path with a catastrophic regular expression. This issue is fixed in version 0.26.0.

vLLM is an inference and serving engine for large language models. Prior to 0.26.0, the validation_exception_handler in vllm/entrypoints/openai/server_utils.py converts FastAPI RequestValidationError objects with str(exc), and sanitize_message in vllm/entrypoints/utils.py does not remove traceback-style file paths, allowing unauthenticated malformed JSON requests to /v1/chat/completions, /v1/completions, /tokenize, and /detokenize to disclose the OS username, home and virtual-environment paths, Python version, internal package structure, line numbers, and endpoint handler names. This issue is fixed in version 0.26.0.

Material for MkDocs is a powerful documentation framework built on top of MkDocs. From 7.2.0 until 9.7.7, the mountSearchSuggest function in src/templates/assets/javascripts/components/search/suggest/index.ts contains a DOM-based cross-site scripting vulnerability in the optional search.suggest feature that allows a crafted q URL parameter to execute JavaScript in a documentation site's origin after user interaction. This issue is fixed in version 9.7.7.

Prowler is a cloud security platform. Prior to 5.37.0, Prowler's HTML output formatter in prowler/lib/outputs/html/html.py inserted finding.resource_tags, assembled by unroll_dict and parse_html_string, into generated reports without HTML escaping, allowing a cloud principal who can modify a scanned resource tag to store HTML or JavaScript that executes when another user opens the report. This issue is fixed in version 5.37.0.

Hugging Face Accelerate through 1.14.0 contains a path traversal vulnerability in load_checkpoint_in_model and load_checkpoint_and_dispatch functions that fail to sanitize weight_map entries from sharded checkpoint indexes. Attackers can supply relative paths with ../ sequences or absolute paths to read arbitrary files, or point shard entries at named pipes to cause indefinite blocking and denial of service.

python-cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. In versions 42.0.0 through 48.0.0, when resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack. The core issue arises in the recursive nature of build_chain_inner, which does not de-duplicate against previously analyzed candidates. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability. This issue is fixed in 49.0.0.

In nltk version 3.9.4, the `nltk.downloader.Downloader._download_package()` function writes downloaded package bytes to disk and may extract them before enforcing SHA-256 or MD5 checksum validation. This allows an attacker to tamper with the package response body for `info.url` through a compromised mirror, malicious proxy, or other source-substitution condition, leading to the installation of attacker-controlled package bytes. The vulnerability can result in malicious corpus or model content being trusted by downstream users or applications.

CVE-2026-67325 is a command injection flaw (CWE-78) in GitPython, a Python library for running Git commands: versions before 3.1.51 use an incomplete blocklist of unsafe git options that does not account for git's long-option prefix abbreviation feature. An attacker triggers it by supplying an abbreviated option name such as 'upload_p' in place of 'upload_pack' in data that reaches GitPython's git command invocations; the abbreviated form evades the unsafe-options guard while git still resolves it to the dangerous option, enabling arbitrary command execution. Per the CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N), the attack is network-based, requires low privileges, and no user interaction, and successful exploitation yields high impact to confidentiality, integrity, and availability with the privileges of the process invoking GitPython. Any environment running GitPython versions before 3.1.51 installed via pip is affected, with risk concentrated in CI/CD pipelines, automation, and services that pass attacker-controlled repository data or arguments into git commands. There are no reports of in-the-wild exploitation (not listed in CISA KEV), EPSS is 1.9% over 30 days (78th percentile), and one public advisory/exploit reference exists (GHSA-2f96-g7mh-g2hx).

Do: Upgrade to GitPython 3.1.51 or later, which closes the abbreviated-option bypass in the unsafe-options guard. Where patching is delayed, strictly validate and restrict attacker-controlled values (refs, URLs, and option strings) passed into GitPython commands so abbreviated long options cannot evade the blocklist. Given the public advisory reference and 1.9% EPSS, prioritize patching internet-facing or multi-tenant services that execute git operations on untrusted repository data.

Prowler is a cloud security platform. Prior to 5.30.3, Prowler's SAML authentication flow trusted the email domain asserted in a SAMLResponse when deciding which tenant should receive the final token, and the ACS finish logic in api/src/backend/api/v1/views.py recalculated the tenant from user.email instead of binding token issuance to the validated SAML configuration. An authenticated attacker with a controlled SAML IdP could complete a valid SAML flow for an attacker-controlled domain while asserting an email address from another configured domain, causing a SAMLToken and tenant-scoped JWT to be issued for the wrong tenant and enabling cross-tenant account takeover. This issue is fixed in version 5.30.3.

JupyterLab Git is a Git extension for JupyterLab. From 0.30.0b3 before 0.54.0, the PlainTextDiff.ts createHeader() method passes Git filenames directly to innerHTML when rendering renamed files in commit history, allowing a crafted filename to execute JavaScript when a victim views the rename diff in the Git History tab. This issue is fixed in version 0.54.0.

A bug in `BaseSerialization.deserialize()` allowed unrestricted `import_string()` of attacker-controlled class paths when the Scheduler / API Server loaded a serialized DAG: a DAG author could embed a malicious trigger into a DAG to gain remote code execution on the API Server / Scheduler process, crossing the Airflow security boundary that DAG-author code must never execute in those processes. Users are advised to upgrade to `apache-airflow` 3.3.0 or later. As a defense-in-depth mitigation, deployments where DAG-author trust is limited can restrict the `[core] allowed_deserialization_classes` config to a narrow allowlist.

Apache Airflow's Google provider operators `GCSToSFTPOperator` and `GCSTimeSpanFileTransformOperator` joined GCS object names returned by the bucket listing API directly to a destination filesystem path without normalisation or containment check. A user with write access to the source GCS bucket (typically a different trust principal than the DAG author — partner uploads, ingest-only service accounts, public-data buckets) could create an object whose name contains `..` segments and cause the DAG run to write the downloaded blob outside the configured destination (the SFTP `destination_path` for `GCSToSFTPOperator`; the worker-local temp directory for `GCSTimeSpanFileTransformOperator`), enabling overwrite of arbitrary files on the SFTP server or the worker host. Affects deployments that ingest from buckets writable by less-trusted principals. Users are advised to upgrade to `apache-airflow-providers-google` 22.2.1 or later.

The Apache Airflow FTP provider's `FTPSHook.get_conn()` created an `ftplib.FTP_TLS` connection but never called `prot_p()`, so although the control channel was TLS-protected the data channel was transmitted in cleartext. Any deployment using `FTPSHook` or `FTPSFileTransmitOperator` to move files over FTPS exposed file contents and credentials-in-transit to a network attacker able to observe the data connection. Upgrade apache-airflow-providers-ftp to `3.15.1` or later, which issues `PROT P` to encrypt the data channel.

OpenHarness /issue and /pr_comments slash commands lack remote_invocable=False protection, allowing remote channel senders to write attacker-controlled Markdown into project context files. Admitted remote attackers can inject malicious content into .openharness/issue.md and .openharness/pr_comments.md files, which are subsequently injected into runtime system prompts, persistently influencing local agent behavior.

OpenHarness ohmo gateway /resume and /summary slash commands default remote_invocable to True, allowing admitted remote senders to enumerate and load arbitrary session snapshots by ID. Attackers can exploit this to access victim snapshots containing private prompts, credentials, tool output, and file paths via shared gateway channels.

Apache Doris MCP Server contains a SQL injection vulnerability in a metadata query path. A user-controlled database name is directly interpolated into a SQL query, and the query is executed without passing the caller's authorization context. This may allow an authenticated attacker, or an anonymous attacker if authentication is disabled, to bypass SQL security validation and access metadata outside the intended database scope. Affected users are recommended to upgrade to Doris version 0.6.1 or later, which fixes the issue.

Crawl4AI before 0.8.7 contains an authentication bypass vulnerability due to a hardcoded default JWT signing key in the Docker API server. Attackers who know the default key can forge valid authentication tokens for any user, bypassing authentication and gaining full access to protected functionality.

picklescan before 0.0.28 fails to detect malicious pickle files that invoke torch.utils._config_module.load_config function within reduce methods. Attackers can craft pickle files embedding arbitrary code that evades detection but executes during pickle.load, enabling remote code execution in supply chain attacks.

picklescan before 0.0.25 fails to detect malicious pickle files that use timeit.timeit() in the __reduce__ method, allowing remote code execution. Attackers can craft pickle files that import dangerous libraries like os and execute arbitrary system commands, which evade picklescan detection and execute when pickle.load() is called.

A security vulnerability has been detected in BerriAI litellm up to 1.82.2. Affected by this issue is the function ui_view_users of the file litellm/proxy/management_endpoints/internal_user_endpoints.py of the component Incomplete Fix CVE-2025-0628. Such manipulation leads to improper authorization. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. The vendor was contacted early about this disclosure.