Search: github.com

## Summary ApostropheCMS widget styles support project-defined schema fields. If a project defines a free-form `string` style field with a CSS `property` and no selector, an editor-controlled value is rendered as an inline CSS declaration. The resulting declaration is then inserted into the widget wrapper's `style="..."` attribute without HTML-attribute escaping. An attacker who can edit the widget can include a double quote in the style value, terminate the `style` attribute, and inject new HTML event-handler attributes. The payload is stored with the widget and executes in the Apostrophe site origin whenever the affected published page is rendered. This is a sibling of CVE-2026-33889 / `GHSA-97v6-998m-fp4g`. The earlier issue escaped from a `<style>` element through a malicious color value. This variant reaches a different sink related to the automatically generated widget wrapper's inline `style` and `class` attributes. ## Details ### Root Cause 1: Free-form string style values retain HTML metacharacters The standard string field converter uses `launder.string()` and length validation. This performs type normalization, not output encoding for an HTML attribute context: [`packages/apostrophe/modules/@apostrophecms/schema/lib/addFieldTypes.js:296-333`](https://github.com/apostrophecms/apostrophe/blob/aa5170c7df9ff9ea5ac2e72a008f12e28dae6ca8/packages/apostrophe/modules/%40apostrophecms/schema/lib/addFieldTypes.js#L296-L333) ```javascript self.addFieldType({ name: 'string', // ... convert(req, field, data, destination) { destination[field.name] = self.apos.launder.string(data[field.name]); destination[field.name] = checkStringLength( destination[field.name], field.min, field.max ); } }); ``` Quotes therefore remain in a value supplied through a style field. ### Root Cause 2: The value is converted into inline CSS without value validation For a field with `property` but no `selector` or media query, `renderScopedStyles()` selects inline rendering. The generic extractor concatenates the configured property and editor-controlled value: [`packages/apostrophe/modules/@apostrophecms/styles/ui/apos/universal/render.mjs:171-228`](https://github.com/apostrophecms/apostrophe/blob/aa5170c7df9ff9ea5ac2e72a008f12e28dae6ca8/packages/apostrophe/modules/%40apostrophecms/styles/ui/apos/universal/render.mjs#L171-L228) [`packages/apostrophe/modules/@apostrophecms/styles/ui/apos/universal/render.mjs:598-647`](https://github.com/apostrophecms/apostrophe/blob/aa5170c7df9ff9ea5ac2e72a008f12e28dae6ca8/packages/apostrophe/modules/%40apostrophecms/styles/ui/apos/universal/render.mjs#L598-L647) ```javascript rule = `${property}: ${normalized.value}${normalized.unit}`; // ... if (isInline) { return { css: '', classes: [ ...storage.classes ], inline: stringifyRules(storage.styles, true) }; } ``` For example, the value below becomes part of a `font-family` declaration: ```text serif" tabindex="0" autofocus onfocus="document.body.dataset.inline='executed' ``` ### Root Cause 3: Attribute values are serialized without HTML escaping `getWidgetAttributes()` places the inline CSS into an attribute tuple, then concatenates every tuple into `key="value"` without encoding `&`, `<`, `>`, `'`, or `"`: [`packages/apostrophe/modules/@apostrophecms/styles/lib/methods.js:251-322`](https://github.com/apostrophecms/apostrophe/blob/aa5170c7df9ff9ea5ac2e72a008f12e28dae6ca8/packages/apostrophe/modules/%40apostrophecms/styles/lib/methods.js#L251-L322) ```javascript if (styleParts.length) { attrs.push( [ 'style', `${styleParts.join(';')};` ] ); } if (options.asObject) { return Object.fromEntries(attrs); } return attrs .map(([ key, value ]) => `${key}="${value}"`) .join(' '); ``` The same raw serializer also makes a project-defined free-form `string` style with `class: true` a potential sibling path, because the string is added to `classes` and later serialized into `class="..."`. The inline-property path was the path dynamically verified. ### Root Cause 4: The unsafe string is used by the automatic public wrapper Styled widgets use `getWidgetAttributes()` to create a wrapper around the rendered widget: [`packages/apostrophe/modules/@apostrophecms/widget-type/index.js:448-457`](https://github.com/apostrophecms/apostrophe/blob/aa5170c7df9ff9ea5ac2e72a008f12e28dae6ca8/packages/apostrophe/modules/%40apostrophecms/widget-type/index.js#L448-L457) ```javascript if (hasStyles && self.options.stylesWrapper !== false) { const styles = self.apos.styles.prepareWidgetStyles(widget); const styleTag = self.apos.styles .getWidgetElements(styles, { scene: req.scene }); const wrapperAttrs = self.apos.styles.getWidgetAttributes(styles); return `${styleTag}<div${wrapperAttrs ? ' ' + wrapperAttrs : ''}>${markup}</div>`; } ``` Consequently, the injected attribute is present on normal public page renders, not only in the editor UI. ### Why the CVE-2026-33889 defense does

## Review scope and evidence limits Package: @apostrophecms/import-export, version 3.7.0. Release tag reviewed: @apostrophecms/import-export@3.7.0, commit 9500b8b0e1d630d5e07fbb5fd2c25ed0943845ce (September 30, 2026). Current main reviewed: 5ce3732be0ebdebb4db0f8ef160c81e8671157e6. The importer, gzip extractor, import permission gate, and core permission implementation have no differences between that release tag and the reviewed main. This follow-up is a static remediation review. We have not repeated the original end-to-end reproductions against the latest release or tested a deployed site. Current exploitability and impact therefore still require maintainer validation; the observations below establish that the reported security checks remain absent in public source. The original emailed PDF contains the original reproduction material. Please refer to that existing private attachment. ## Archive duplicate continuation permits unauthorized published-content replacement The overrideDuplicates() continuation still accepts client-supplied replacement choices, rather than binding them to a server-maintained, user-owned duplicate analysis. The replacement and write helpers do not establish a single canonical resource identity and authorization context before the update. This leaves the reported gap between draft editing authority and the published target selected for replacement unresolved at source level. The original report describes a contributor crossing the publication boundary through duplicate replacement on an import-enabled localized type. We have not repeated that end-to-end sequence on 3.7.0. Suggested remediation: bind continuation state to the initiating user, archive, job, permitted source/target mapping, locale and mode; reject inconsistent identity metadata; derive permissions from the actual loaded target and require publication authority for published targets. Source: overrideDuplicates(), replaceDocId(), and insertOrUpdateDoc() in the [importer](https://github.com/apostrophecms/apostrophe/blob/5ce3732be0ebdebb4db0f8ef160c81e8671157e6/packages/import-export/lib/methods/import.js). ## Coordination Vivek R / Winfunc Original reporting team: Mufeed VH / Winfunc

Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description field; the metadata block maps to the form fields. Set the patched version at release; publish when the fix ships._ --- - **Ecosystem:** Maven - **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (task store / authorization) - **Affected versions:** `<= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix) - **Patched version:** _(the release that carries the fix, e.g. 1.2.1.Final)_ - **CWE:** CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization) - **Severity:** High - **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` (7.5, High) --- ## Details The default task store performs no authorization on task reads. `InMemoryTaskStore`'s no-arg constructor sets `authorizationProvider = null`, and `InMemoryTaskStore.get(String taskId)` is a bare map lookup with no authorization check regardless of provider: ```java public InMemoryTaskStore() { this.authorizationProvider = null; // default wiring } @Override public @Nullable Task get(String taskId) { return tasks.get(taskId); // no owner / caller check } ``` Authorization is enforced only when the application both supplies a `TaskAuthorizationProvider` *and* routes requests through `AuthorizationRequestHandlerDecorator` (via CDI), which checks ownership before delegating. A server that uses the default store, or wires `DefaultRequestHandler.builder().build()` manually, or integrates through a non-CDI stack (e.g. Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is the unsafe one. A caller can read a task created by another caller simply by knowing or guessing its id. ## Summary With the SDK's default configuration, task reads are not authorized: any caller can retrieve a task (including its status, context, message history, and artifacts) created by another caller, by supplying the task id. ## PoC Using only the real production classes wired the default way (no mocks): 1. Construct the default store: `InMemoryTaskStore store = new InMemoryTaskStore();` (no-arg constructor, so no authorization provider). 2. As one caller, save a task: `store.save(victimTask, false);` with id `victim-task-42`. 3. As a second, unrelated caller with no auth context, read it back: `store.get("victim-task-42")`. The second caller receives the first caller's task in full, with no authorization check: ``` unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx ``` Verified on `main` (commit `72d220c`, JDK 21) and reproduces unchanged on `1.2.0.Final`. ## Impact Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on the default wiring, one caller can enumerate and read another caller's tasks, including task status, context id, the message history, and any artifacts the task carries, which for agent workloads is frequently sensitive input and generated content. Because the insecure behaviour is the default rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference deployment the transport endpoints are served without authentication enforced, so the read is reachable by an unauthenticated caller (`PR:N`). CVSS is scored against the default configuration as shipped. ## Remediation Fail closed by default: deny task reads when no authorization provider is configured, rather than treating a missing provider as allow-all, and apply the authorization check in the store's `get` path (not only in `list` and the CDI decorator) so it holds regardless of how the handler is wired. If the current permissive default is retained for single-user/testing scenarios, emit a prominent startup warning when the server comes up with no authorization provider so it cannot be shipped by accident. ## Workarounds Until a fixed release, configure a `TaskAuthorizationProvider` and ensure requests are routed through the authorization decorator (CDI wiring), rather than relying on the default no-arg store or a manually built handler. ## References - CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html - CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html

OVHcloud's open-source CLI tool was compromised on GitHub, with attacker-modified versions 0.11.0 through 0.15.0 containing malware designed to steal developer secrets. The compromise occurred via a hijacked developer GitHub account, allowing malicious releases to be published without CI/CD pipeline interference. The incident was detected and blocked within hours, and OVHcloud has enabled GitHub's release immutability feature to prevent recurrence. Users who downloaded affected versions are urged to revoke all secrets and perform system cleanup. The attack is linked to the GlassWorm threat actor group, known for targeting software development ecosystems. Source builds and Docker images were unaffected.

@e2e-dev/github before 0.4.1 contains an improper authorization vulnerability that allows pull request commenters to hijack CI test reports by posting comments with the predictable marker. Because findComment and upsertComment in post.ts never check the comment author, attackers can receive results in their own comment and edit failures to passes, or suppress genuine reports entirely.

## Summary A small attacker-supplied TIFF can be opened and loaded normally, then reach an out-of-bounds read when an application saves it back to TIFF with retained metadata. The fixed reproducer is a 1×1, 16-bit grayscale, PackBits-compressed TIFF containing tag 320 (ColorMap) with **768 SHORT values**: three zero-filled planes of 256 entries each. No Python object is forged and no metadata is injected after loading. Pillow's TIFF encoder allocates **768 × 2 = 1536 bytes**, then passes three plane pointers separated by 256 SHORT entries to libtiff. With `BitsPerSample = 16`, libtiff instead expects **65536 SHORT values per plane** and attempts a **131072-byte read** from a plane pointer. Existing ASAN observations identify a heap-buffer-overflow READ crossing the 1536-byte allocation made in `PyImaging_LibTiffEncoderNew`. The malformed ColorMap need not be a valid palette for this grayscale image. The issue is that accepted metadata is forwarded on save without reconciling the fixed plane extent with the effective sample depth. Opening/loading alone is not the demonstrated fault; the encoder path is required. ## Impact and prerequisites An application must accept the input, retain the relevant TIFF metadata, and invoke the libtiff-backed TIFF save path. The observed consequence is an out-of-bounds read and ASAN termination. Process-memory exposure during encoding is a potential consequence, **not demonstrated by extracting arbitrary heap contents in this report**. No arbitrary read primitive, full memory-disclosure chain, code execution, address-space bypass, or cross-process effect is claimed. The 131072-byte attempted copy is not the number of bytes proven disclosed. This report does not run a synthetic-canary serializer or collect an unsanitized encoded output. ## Tested environment and limits of the evidence The existing observations were recorded on August 30, 2026, with **CPython 3.11.8 on macOS ARM64**, using the unmodified official **Pillow 12.3.0** wheel and its bundled **libtiff 4.7.1**: - Wheel: `pillow-12.3.0-cp311-cp311-macosx_11_0_arm64.whl` - Wheel size: `4785266` bytes - Wheel SHA-256: `37d6d0a00072fd2948eb22bce7e1475f34569d90c87c59f7a2ec59541b77f7a6` - Pillow source revision: `bb1d8e8ab8d29048624d96e3ee53cecf7c13d13d` - Bundled libtiff SHA-256: `e8988717b7470394a47d5ccd343130796b24ee70b6d885d3818e0e0b53238be1` Apple's ASAN runtime was injected at process startup. This is **not an ASAN-rebuilt Pillow wheel**; allocation/memcpy interception detects the reported boundary violation, but the wheel's native instructions are not comprehensively instrumented. Only this concrete full-package environment is established here. No affected-version range, current development-branch result, or patched release is asserted. Severity is **Unknown**; no CVSS score is proposed. Separate earlier evidence reached the original Pillow 8.0.1 encoder constructor compiled as a component against a modern Python/libtiff environment. **That was not a complete Pillow 8.0.1 installation** and does not establish the historical package's full runtime behavior. It is not part of this reproducer or an affected-version range. ## Observed evidence and controls The earlier integration harness performed the natural sequence `Image.open(BytesIO(input))`, `image.load()`, then `image.save(BytesIO(), format="TIFF")`, without replacing the image's metadata. Each case was recorded three times: | Original fixture | Bytes | Recorded result | | --- | ---: | --- | | `colormap16` | 1685 | Loaded as `I;16`; save terminated with ASAN exit 86, READ of size 131072 crossing a 1536-byte heap region (3/3). | | `colormap8` | 1684 | Same fixed ColorMap, but 8-bit samples; save succeeded and retained SHORT/count 768 (3/3). | | `colormap_absent` | 137 | Same 16-bit geometry without ColorMap; save succeeded (3/3). | Address-free summary of the recorded native diagnostic: ```text AddressSanitizer: heap-buffer-overflow READ of size 131072 0 bytes after 1536-byte region Copy path: memcpy -> _TIFFmemcpy -> setByteArray -> _TIFFsetShortArrayExt -> _TIFFVSetField -> TIFFVSetField -> ImagingLibTiffSetField -> PyImaging_LibTiffEncoderNew Allocation: calloc -> PyImaging_LibTiffEncoderNew ``` Input SHA-256 values (also enforced inside the script): - `colormap16`: `5f38e0ead90b97949fb0c98c63f9c68d00ba9181db6631ecb8927376dcc75f4d` - `colormap8`: `fdb26d9135549ed44824901985086c5ee4f06515699ca3291e498c523935405c` - `colormap_absent`: `bd54979624f3ffb713342e0458caff9e17c477f940cda2f0960feebfabbc9556` ## Root cause and source references - [Pillow `src/encode.c`, lines 870–899, pinned revision](https://github.com/python-pillow/Pillow/blob/bb1d8e8ab8d29048624d96e3ee53cecf7c13d13d/src/encode.c#L870): the ColorMap tuple must contain exactly 768 entries; a 1536-byte allocation is passed with a fixed stride of 256. The check does not reconcile that extent with `BitsPerSample`. - [Pillow `src/PIL/TiffImagePlugin.py`, lines 1944–19

A security update for the google-osconfig-agent addresses CVE-2026-63209, a signed integer overflow vulnerability in the github.com/klauspost/compress library's s2.NewDict() function. This flaw allows an attacker to bypass repeat index validation and cause a process crash. The update includes upgrading the compress library to version v1.18.7 and other fixes.

This content describes an open-source phishing forensics engine named phish-zero that claims 98.32% accuracy and operates with a zero-egress architecture to avoid leaking corporate click data. It uses local neural phishing detection, character n-gram TF-IDF vectorizers, and flags for TLD abuse. The post is a community share on Reddit and includes a link to the GitHub repository. There is no indication of a security vulnerability or active threat associated with this tool itself.

CVE-2026-111876 is a command injection vulnerability in the alexpasmantier television software up to version 0.15.9. The flaw exists in the Entry::output function within the television/channels/entry.rs file. Exploitation requires local access and involves manipulating the 'raw' argument to execute arbitrary commands. The issue was reported but the related GitHub issue was closed as 'not planned' for a fix. The vulnerability has a medium severity with a CVSS 4.8 score.

CVE-2026-111866 is a medium severity SQL injection vulnerability in the nemoTyrant manong product affecting the function cache/del_cache/arr2sql in func.php. The vulnerability allows remote attackers to manipulate SQL queries. The product uses a rolling release model, and no specific affected or fixed versions are identified. The related GitHub issue was closed as completed, but no clear fix commit is known.

CVE-2026-102941 is a high severity vulnerability in the Go library github.com/gomarkdown/markdown, which is used for parsing markdown content. The vulnerability has an impact on availability but does not affect confidentiality or integrity. No specific affected versions or patch information are provided.

The GhostAction campaign is a supply chain attack targeting GitHub developer accounts and repositories. It compromises user accounts to inject malicious GitHub Actions workflows that steal CI/CD secrets, cloud credentials, and API keys. The campaign has affected about 1,900 GitHub accounts and over 30,000 repositories as of October 2026. GitHub has intervened to prevent the malicious workflows from running in recent waves of the attack.

Variola is a modular Windows malware implant linked to a ClickFix intrusion, designed for persistent host identity and secure command-and-control communications. It supports dynamic loading of modules for credential theft, browser manipulation, and session hijacking, with capabilities typical of banking trojans such as Chromium browser injection and VNC-style remote access. The implant uses strong cryptographic methods for communication security and shows active development with multiple builds found in a public GitHub repository. No patch or remediation information is provided, and no known exploits in the wild have been reported.

If a certain set of MathML tags are enabled, an attacker can inject arbitrary JavaScript code into the user's browser. The `annotation-xml` tag has slightly different behavior than the other "integration point" tags in MathML and SVG, but ammonia didn't handle it, so it didn't correctly strip the namespace-incompatible tags. This vulnerability only has an effect when the `math` and `annotation-xml` tags are both enabled, but the `encoding` attribute is disabled, because it relies on the following sequence of steps: 1. User writes code like `<math><annotation-xml encoding="text/html"><gadget></annotation-xml></math>`. 2. Namespace filtering checks the DOM, and it passes. `<gadget>` is parsed as HTML. 3. Attribute filter strips it down to `<math><annotation-xml><gadget></annotation-xml></math>`. Because the encoding attribute is gone, `<gadget>` is now parsed as MathML. 4. The gadget is written in such a way that it exploits the parsing differences between HTML and MathML. Additionally, the gadget can only be written using a tag that is parsed as raw text in HTML. These [elements] are: * title * textarea * xmp * iframe * noembed * noframes * plaintext * noscript * style * script Applications that do not explicitly allow any of these tags should not be affected, since none are allowed by default. [elements]: https://github.com/servo/html5ever/blob/045a0378f2b0f8d4a350793899cf722a2a9b3d11/html5ever/src/tree_builder/rules.rs ### Impact Low: Requires both MathML and at least one raw-text HTML tag to be enabled, and most websites don't enable either of those. ### Patches - https://github.com/rust-ammonia/ammonia/pull/245 (released in 4.1.3) - https://github.com/rust-ammonia/ammonia/pull/244 (released in 4.0.2) - https://github.com/rust-ammonia/ammonia/pull/243 (released in 3.3.2) ### Workarounds Call <code>builder.[add_clean_content_tags](https://docs.rs/ammonia/latest/ammonia/struct.Builder.html#method.add_clean_content_tags)("annotation-xml")</code> to remove the annotation-xml element and all of its children, including the XSS gadget.

A vulnerability in the golang-github-getkin-kin-openapi project versions from 0.136.0 up to 0.149.0 allows unauthenticated remote clients to trigger a nil-pointer panic. This occurs due to missing nil-items guards in three openapi3filter decoder paths when handling legal OpenAPI 3.1 array schemas. The issue can be triggered via specific array query parameters, deepObject query parameters with array properties, or application/x-www-form-urlencoded request bodies with array properties inside composed schemas. The flaw is fixed in version 0.149.0.

## Summary When cache interception is enabled, `@opennextjs/cloudflare` can interpret percent-encoded paths differently during middleware matching and cache lookup. An encoded request may fail to match authorization middleware, then be decoded into the cache key of a protected route. The cached response may consequently be returned without invoking the middleware. `enableCacheInterception` is disabled by default. ## Impact A remote unauthenticated attacker may retrieve cached content from routes intended to be protected by middleware. An application is affected when it: - explicitly enables `enableCacheInterception`; - relies on middleware for access control; and - has a matching cached route. ## Details Middleware matching previously used the encoded request pathname, while cache interception decoded the pathname before selecting a cache entry. For example, consider an application with: - middleware matcher `/admin/:path*`; - middleware returning `401 Authentication required` for `/admin`; - a statically generated, cached `/admin` route; and - cache interception enabled: ```ts export default defineCloudflareConfig({ incrementalCache: staticAssetsIncrementalCache, enableCacheInterception: true, }); ``` An attacker can request: ```http GET /%61dmin ``` The encoded pathname does not match `/admin/:path*`, so the authorization middleware is not invoked. Cache interception then decodes `%61dmin` to `admin` and may return the cached `/admin` response: ```http HTTP/1.1 200 OK x-opennext-cache: HIT Protected content ``` Malformed paths exposed an additional inconsistency. For example: ```http GET /%61dmin/%ZZ ``` The previous implementation decoded each segment independently. It decoded `%61dmin` to `admin` but retained the malformed `%ZZ` segment, allowing cache lookup to continue using a partially decoded pathname. ## Patches The fix aligns encoded-path handling across middleware matching and cache lookup, and rejects malformed paths instead of partially decoding them. See the upstream fixes in [opennextjs-aws#1199](https://github.com/opennextjs/opennextjs-aws/pull/1199) and [opennextjs-aws#1200](https://github.com/opennextjs/opennextjs-aws/pull/1200). Users should upgrade to `@opennextjs/cloudflare@1.20.2` or later. ## Workarounds If upgrading is not immediately possible for an application: 1. Disable cache interception by removing `enableCacheInterception: true`. 2. Enforce authorization inside protected route handlers rather than relying exclusively on middleware. 3. Reject encoded paths for protected routes at a trusted proxy before they reach the Worker. Adding individual encoded matcher variants is not a complete workaround because pathnames can have multiple equivalent encodings.

A vulnerability in the golang-github-getkin-kin-openapi project versions from 0.136.0 up to but not including 0.143.0 allows a remote unauthenticated attacker to cause a nil-pointer panic. This occurs because the openapi3filter component improperly accepts OpenAPI 3.1 array schemas without the required items keyword and dereferences a nil Schema.Items value during request or response validation. The issue does not affect OpenAPI 3.0 documents and is fixed in version 0.143.0.

A vulnerability in the golang github getkin kin openapi project affects versions from 0.145.0 up to but not including 0.146.0. The issue involves repeated calls to regexp.MustCompile inside a loop in the openapi3filter component, causing excessive resource consumption when processing deepObject query parameters. This can be triggered by an unauthenticated remote client sending requests with many unrelated query keys, leading to increased CPU and memory usage. The flaw is fixed in version 0.146.0.

A vulnerability in golang-github-getkin-kin-openapi prior to version 0.145.0 allows a panic during loading of specially crafted OpenAPI documents. The openapi3.Loader component can dereference a nil SchemaRef.Value when resolving a self-referential additionalProperties JSON Reference, causing the loading process to panic. This issue is fixed in version 0.145.0.

CVE-2026-100349 is a NULL pointer dereference vulnerability in the kin-openapi library (github.com/getkin/kin-openapi) affecting versions up to 0.145.0. The issue occurs when a response header in an OpenAPI spec declares a 'content' field instead of a 'schema', causing the ValidateResponse function to panic due to a nil pointer dereference. This crash happens even though the document passes validation, leading to a process crash on every call to the affected operation. The vulnerability can cause denial of service if the spec is attacker-controlled or comes from an untrusted source.