GraphQL | Techlist.io

gitlabAug 12, 20263 min readCurated summary

GitLab Patch Release: 19.2.2, 19.1.4, 19.0.6 | GitLab Docs

GitLab released patch versions 19.2.2, 19.1.4, and 19.0.6 on August 12, 2026, addressing multiple security and bug issues in CE and EE. The release fixes vulnerabilities involving cross-site scripting, authorization bypasses, privilege escalation, data exposure, and denial of service. Self-managed installations should upgrade immediately; GitLab.com is already patched, and GitLab Dedicated customers need no action. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - GitLab recommends upgrading all affected self-managed installations to the latest patch for their supported release line. - Patch releases may be scheduled or issued ad hoc for critical vulnerabilities. - Security issues are generally disclosed publicly 90 days after the release containing their fixes. - Unless a deployment type is explicitly excluded, omnibus, source, Helm chart, and other installation types are affected. ## Cross-Site Scripting Vulnerabilities - **CVE-2026-15217** affects Analytics Dashboards table field configuration. - Improper neutralization of user-controlled values could allow XSS in table cell content. - CVSS: **8.7**. - **CVE-2026-15216** affects Analytics Dashboards pagination controls. - User-controlled data could be rendered unsafely and enable XSS. - CVSS: **8.7**. - **CVE-2026-16627** affects the CI manual job confirmation modal. - Authenticated developers could potentially escalate privileges through unsanitized HTML. - CVSS: **7.7**. ## Authorization and Privilege Issues - **CVE-2026-15423** affects the CI/CD pipeline API. - Developer-role users could run pipelines on protected branches without the required push permissions. - CVSS: **8.5**. - **CVE-2026-19228** affects the Duo Workflow Service in GitLab EE. - An authenticated user could attribute AI usage to another namespace. - CVSS: **8.5**. - **CVE-2026-16494** affects the EE ProjectsController. - Missing checks could let authenticated users modify project settings reserved for higher-privileged roles. - CVSS: **7.1**. - **CVE-2026-8667** affects the npm distribution-tags endpoint. - Developers could modify certain package registry metadata without maintainer permissions. - CVSS: **4.3**. ## Information Disclosure and API Access - **CVE-2026-6821** affects the EE merge requests API. - Authenticated users could bypass IP-based restrictions and read limited merge request information from private projects. - CVSS: **4.3**. - **CVE-2026-4879** affects the external status check API. - Developers could view status check configuration restricted to higher-privileged roles. - CVSS: **4.3**. ## Denial of Service - **CVE-2026-7427** affects the GraphQL API JSON parser. - Improper input validation could allow unauthenticated attackers to cause a denial of service. - CVSS: **5.3**. Self-managed GitLab administrators should apply 19.2.2, 19.1.4, or 19.0.6 immediately, depending on their release branch, to receive these security fixes.

Read original

GraphQL CI/CD Gitlab Npm+3

gitlabJul 8, 20263 min readCurated summary

GitLab Patch Release: 19.1.2, 19.0.4, 18.11.7 | GitLab Docs

GitLab released patch versions 19.1.2, 19.0.4, and 18.11.7 on July 8, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. GitLab strongly recommends that all affected self-managed installations upgrade immediately; GitLab.com is already patched, while GitLab Dedicated customers need no action. The release includes fixes ranging from cross-site scripting and HTML injection to authorization and credential-access issues. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Patch releases address security vulnerabilities and important bugs. - Scheduled patch releases occur twice monthly, on the second and fourth Wednesdays. - Vulnerability details are generally made public 90 days after the fixing release. - All self-managed deployments—including Omnibus, source, and Helm installations—should upgrade to the latest supported patch version. ## High-Severity Browser Script Injection Fixes - **CVE-2026-6896 — CVSS 8.7** - Affected the vulnerability evidence table renderer in GitLab EE. - An authenticated developer could potentially execute scripts in another user’s browser through unsanitized input. - **CVE-2026-13320 — CVSS 7.3** - Affected wiki markup rendering in GitLab CE and EE. - Improper sanitization could allow an authenticated user to execute scripts in another user’s browser. ## Authorization and Information Disclosure Fixes - **CVE-2026-11827 — CVSS 4.9** - Affected repository mirroring in GitLab EE. - Maintainers could potentially access credentials stored for another user because of inadequate authorization checks. - **CVE-2026-8472 — CVSS 4.3** - Affected work items in GitLab EE. - Users with minimal access could read metadata from work items in private projects. - **CVE-2026-7492 — CVSS 4.3** - Affected commit discussion display in GitLab CE and EE. - Unauthenticated users could determine whether a private project existed through cross-project references. ## Repository and Configuration Security Fixes - **CVE-2025-12506 — CVSS 3.5** - Addressed ambiguous Git tag or branch references. - A repository could display content in the web interface that differed from the content available for download. - **CVE-2026-13151 — CVSS 2.7** - Fixed incorrect authorization in GitLab EE group-level settings. - Some authenticated users could modify settings beyond their intended permissions. - **CVE-2026-6352 — CVSS 2.7** - Fixed authorization flaws in compliance violation management. - Auditor-level users could modify compliance records through certain GraphQL operations. ## Bug Fixes in GitLab 19.1.2 - Set and backfilled `organization_id` for OAuth applications before constraint validation. - Upgraded Go to version 1.25.11. - Fixed multi-architecture tags on the legacy container registry path. - Improved external agent flows by using commit author and committer identities. - Fixed ClickHouse 23.x compatibility for `ci_finished_builds`. - Added cursor pagination and checkpoint limits to Duo workflow event retrieval. - Reverted a problematic merge request and removed an obsolete active-user cron schedule. - Fixed approval-rule regressions affecting Developer-authored merge requests. - Resolved a memory leak on the commits page caused by eager description loading. - Updated the builder image revision to `5.60.1`. ## Additional Fixes in GitLab 19.0.4 - Backported the OAuth `organization_id` fixes. - Added Skopeo registry authentication through `CI_JOB_TOKEN`. - The release also contains further backported fixes, though the provided release notes are truncated before listing them. Self-managed GitLab administrators should upgrade to 19.1.2, 19.0.4, or 18.11.7 according to their supported release line, prioritizing the update because of the two high-severity script-injection vulnerabilities.

Read original

GraphQL Gitlab Oauth Cross Site Scripting+4

gitlabMay 28, 20263 min readCurated summary

GitLab Patch Release: 19.0.1, 18.11.4, 18.10.7 | GitLab Docs

GitLab released patch versions 19.0.1, 18.11.4, and 18.10.7 on May 27, 2026, addressing multiple security vulnerabilities and bug fixes across CE and EE. The most serious issue, rated CVSS 8.2, affected Duo AI workflow identity resolution, while other fixes addressed authorization, data exposure, denial-of-service, and CI access issues. GitLab strongly recommends that self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - The releases include fixes for supported versions and should be applied as soon as possible. - GitLab publishes vulnerability details publicly 30 days after the release containing the fix. - Patch releases are generally issued on the second and fourth Wednesdays, with critical ad-hoc releases possible. ## Security Fixes - **CVE-2026-4868 — Duo AI workflow runners, EE** - CVSS 8.2. - Under certain conditions, an authenticated user could cause workflows to run under another user’s identity. - Affected versions were EE releases before 18.10.7, 18.11.4, and 19.0.1. - **CVE-2026-1402 — Wiki denial of service, CE/EE** - CVSS 6.5. - Insufficient validation could allow an authenticated user to trigger a denial-of-service condition. - **CVE-2026-6713 — GraphQL WorkItem API, CE/EE** - CVSS 5.3. - Incorrect authorization checks could allow unauthorized enumeration of private projects. - **CVE-2026-5296 — Duo Workflows API, EE** - CVSS 4.3. - Developer-level users could bypass restrictions on group-level foundational flows in certain configurations. - **CVE-2026-2601 — Operations, EE** - CVSS 4.3. - Developers could potentially access sensitive deployment data because of missing authorization checks. - **CVE-2026-8716 — Pipelines, CE/EE** - CVSS 4.3. - Incorrect name resolution could expose CI data from an unintended ref type. - **CVE-2026-2710 — Authentication endpoints, CE/EE** - CVSS 4.3. - Blocked project access tokens could continue accessing private resources in certain cases. ## Bug Fixes in 19.0.1 - Added write permissions for repositories in job-token fine-grained permissions. - Fixed broken trial calls to action on the self-managed GitLab Credits dashboard. - Updated API security remediation guidance. - Removed Helm-based release-environment QA coverage. - Backported final 19.0 release notes and related maintenance changes. ## Bug Fixes in 18.11.4 - Updated Ruby thread scheduler behavior and Zlib to version 3.2.3. - Upgraded GitLab Shell to 14.50.0 and Elasticsearch indexer to 5.14.7. - Fixed lost comments when moving wiki pages. - Improved subgroup provisioning, synchronization workers, pipeline cancellation, and build handling. - Corrected issues affecting swimlanes, epic boards, CI catalog filtering, and pipeline traces. - Improved advanced-search bulk indexing by using the primary database connection. - Added AI workflow scope support and endpoint handling for diagram proxies. - Included performance optimizations for license approval workflows. ## Recommended Action Administrators of affected self-managed GitLab installations should upgrade to 19.0.1, 18.11.4, or 18.10.7 immediately, using the appropriate deployment method such as Omnibus, source, or Helm.

Read original

GraphQL CI/CD Gitlab Elasticsearch+4

gitlabMay 13, 20262 min readCurated summary

GitLab Patch Release: 18.11.3, 18.10.6, 18.9.7 | GitLab Docs

On May 13, 2026, GitLab released patch versions 18.11.3, 18.10.6, and 18.9.7 for CE and EE. The releases address multiple high-severity security vulnerabilities, including cross-site scripting, denial of service, authorization, and access-control issues. GitLab strongly recommends that all affected self-managed installations upgrade immediately. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - GitLab.com is already patched; GitLab Dedicated customers do not need to act. - Patch releases may be scheduled or issued urgently for critical vulnerabilities. - Security vulnerability details are published publicly 30 days after the fixing release. - Unless otherwise specified, all deployment types—including Omnibus, source installations, and Helm charts—are affected. ## Cross-Site Scripting Vulnerabilities Several authenticated-user XSS vulnerabilities could allow arbitrary JavaScript to execute in other users’ browsers: - **CVE-2026-7481**: Affects EE Analytics dashboard chart rendering; exploitable by users with Developer permissions. - **CVE-2026-5297**: Affects global search in CE and EE. - **CVE-2026-6073**: Affects EE Duo Agent output rendering. - **CVE-2026-7377**: Affects customizable EE Analytics dashboards. - Each issue received a **CVSS score of 8.7** and resulted from improper input sanitization. ## Denial-of-Service Vulnerabilities The release fixes multiple unauthenticated denial-of-service issues involving malformed requests or files: - **CVE-2026-1659**: Specially crafted requests to the CI/CD job update API could disrupt service. - **CVE-2025-14870**: Malformed JSON payloads targeting the Duo Workflows API could cause a denial of service. - **CVE-2025-14869**: Certain internal API endpoints were vulnerable to specially crafted payloads. - **CVE-2026-1184**: A specially crafted file uploaded through Insights Configuration could cause service disruption. - The API-related issues were rated **CVSS 7.5**; the Insights issue was rated **6.5**. ## Authorization and Access-Control Issues - **CVE-2026-1322**: An authenticated user with a `read_api`-scoped OAuth application could create issues and comment on private projects through GraphQL, due to improper token-scope enforcement. It received a **CVSS score of 6.8**. - **CVE-2026-4524**: Authenticated users could access confidential issue content in public projects through the Issues API without proper authorization checks. It received a **CVSS score of 6.5**. ## Recommended Action Self-managed GitLab administrators should upgrade to the latest supported patch release—18.11.3, 18.10.6, or 18.9.7—as soon as possible, particularly because several vulnerabilities are remotely exploitable and require little or no authentication.

Read original

GraphQL Gitlab JavaScript Oauth+3

gitlabMay 7, 20262 min readCurated summary

A leaked personal access token shouldn't expose every project its owner can reach. Fine-grained PATs scope each token’s permissions to the job.

Fine-grained personal access tokens (PATs) reduce credential exposure by limiting each token to only the projects, groups, resources, and actions required for a specific task. GitLab’s beta lets users replace broad `api` or `read_api` tokens with narrowly scoped permissions, reducing the impact of leaks. The feature is not yet recommended for production because coverage is still incomplete. ## Why Narrow PAT Privileges - Broad, user-scoped tokens can access every project the user can reach. - A leaked token might expose source code, pipelines, container images, or CI/CD variables across many projects. - Fine-grained tokens limit both access and potential remediation to the affected project or resource. - They complement lifetime limits and automatic revocation. ## How Fine-Grained Tokens Work - Scope access by location: - Personal projects - All projects and groups where the user is a member - Specifically selected projects and groups - Assign independent Create, Read, Update, and Delete permissions. - Supported resources include Issues, Merge Requests, Pipelines, Repositories, and Container Registry. - Example: a container-publishing pipeline can receive Create and Read access only to one project’s registry. ## Auditing and Beta Coverage - The token management table displays scopes and per-resource permissions for all tokens. - This makes over-privileged credentials easier to identify during reviews. - Fine-grained PATs currently support about 75% of REST API endpoints. - GitLab plans to add remaining REST endpoints and expand GraphQL support. - Existing traditional PATs continue working alongside fine-grained tokens during the beta. ## Getting Started - Go to **User Settings → Personal Access Tokens**. - Select **Fine-grained token** when generating a token. - Choose the permitted projects or groups and assign resource permissions. - GitLab recommends avoiding fine-grained PATs in production until general availability. Teams should begin evaluating fine-grained tokens for automation and adopt one token per job, with the smallest practical scope. Feedback during the beta will help shape broader endpoint coverage and future improvements.

Read original

GraphQL Gitlab Rest Api Api Security+3

gitlabApr 29, 20262 min readCurated summary

GitLab Patch Release: 18.11.2, 18.10.5 | GitLab Docs

GitLab released patch versions 18.11.2 and 18.10.5 on April 29, 2026, for Community and Enterprise Editions. The releases address an observability gap affecting disaster recovery RTO/RPO commitments for GitLab Dedicated and fix several regressions and bugs. No security fixes are included. ## Changes in GitLab 18.11.2 - Reverts the `ia-refactor-role-permission-enablement` merge. - Adds Code Suggestions to DAP-supported features for self-hosted models. - Preserves DAP code review access for Duo Core users. - Clears persisted filters when loading the `/work_items` page. - Adds a GraphQL mutation for retrying failed reassignment operations. - Resolves Sidekiq spikes when users are banned. - Fixes MCP OAuth discovery for installations using relative URLs. - Adds the `*_oldest_unsynced_time` metric. - Includes additional changes related to disaster recovery observability. ## Changes in GitLab 18.10.5 - Adds Code Suggestions support for self-hosted models through DAP. - Updates the Duo CLI version used for remote flows. - Skips three migrations that reference dropped tables. - Preserves DAP code review access for Duo Core users. - Resolves Sidekiq spikes caused when users are banned. - Fixes missing `model_definitions` in self-hosted feature settings. - Prevents `CreateOrUpdateDefaultTrackedContextWorker` from running on Geo secondaries. - Adds the `*_oldest_unsynced_time` metric. ## Upgrade and migration impact - **Single-node installations:** Expect downtime because migrations must finish before GitLab starts. - **Multi-node installations:** Zero-downtime procedures can allow upgrades without downtime. - **Regular migrations:** Included in version 18.10.5. - **Post-deploy migrations:** Included in both 18.11.2 and 18.10.5. Administrators should follow GitLab’s standard upgrade guidance for single-node systems and zero-downtime procedures for multi-node deployments before updating.

Read original

GraphQL Observability Gitlab Database Migrations+4

gitlabApr 22, 20263 min readCurated summary

GitLab Patch Release: 18.11.1, 18.10.4, 18.9.6 | GitLab Docs

GitLab released patch versions 18.11.1, 18.10.4, and 18.9.6 on April 22, 2026, addressing multiple security vulnerabilities and bugs in CE and EE. Self-managed installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes include unauthenticated GraphQL and browser-based attacks, several denial-of-service flaws, and access-control weaknesses. ## Release Scope and Upgrade Guidance - Applies to GitLab Community Edition and Enterprise Edition. - Affects all deployment types unless otherwise specified, including Omnibus, source installations, and Helm charts. - Recommended fixed versions: - 18.11.1 - 18.10.4 - 18.9.6 - GitLab issues detailing security vulnerabilities are made public 30 days after the relevant patch release. - GitLab publishes both scheduled patch releases, issued on the second and fourth Wednesdays, and ad-hoc critical patches for high-severity vulnerabilities. ## High-Severity Vulnerabilities - **CVE-2026-4922 — GraphQL CSRF** - CVSS 8.1. - An unauthenticated attacker could execute GraphQL mutations on behalf of an authenticated user because of insufficient CSRF protection. - Affects versions before 18.9.6, 18.10.4, and 18.11.1. - **CVE-2026-5816 — Web IDE path validation** - CVSS 8.0. - Under certain conditions, improper path validation could allow unauthenticated attackers to execute arbitrary JavaScript in a user’s browser session. - Affects the 18.10 and 18.11 release lines before the listed patches. - **CVE-2026-5262 — Storybook cross-site scripting** - CVSS 8.0. - Improper input validation could allow unauthenticated access to tokens in the Storybook development environment. - Affects versions from 16.1 through the unpatched 18.9, 18.10, and 18.11 releases. ## Denial-of-Service Fixes - **CVE-2025-0186:** Crafted requests to the discussions endpoint could exhaust server resources. - **CVE-2026-1660:** Improper input validation during Jira issue imports could enable resource exhaustion. - **CVE-2025-6016:** Insufficient limits when retrieving notes could cause service disruption. - **CVE-2025-3922:** Resource-allocation weaknesses in the GraphQL API could allow authenticated users to overwhelm the system. - Each issue carries a CVSS score of 6.5 and generally requires authentication. ## Access-Control and Session Fixes - **CVE-2026-6515 — Virtual registry credentials** - CVSS 5.4. - Invalidated or incorrectly scoped credentials could continue accessing Virtual Registries. - **CVE-2026-5377 — Confidential issue titles** - CVSS 4.3. - Authenticated users could potentially view titles of confidential or private issues in public projects. - **CVE-2026-3254 — Mermaid sandbox** - CVSS 3.5. - Improper validation could allow authenticated users to load unauthorized content into another user’s browser. - The release also lists **CVE-2025-9957**, involving improper access control in the project fork relationship API; the provided text does not include its full impact or severity details. Self-managed GitLab administrators should apply the appropriate patch release as soon as possible, especially because several vulnerabilities permit unauthenticated browser or API attacks.

Read original

GraphQL Gitlab Vulnerability Management Cross Site Scripting+4

gitlabApr 8, 20262 min readCurated summary

GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9 | GitLab Docs

GitLab released patch versions 18.10.3, 18.9.5, and 18.8.9 on April 8, 2026, addressing important security and bug fixes. Self-managed CE and EE installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes cover unauthorized access, denial-of-service vulnerabilities, code injection, XSS, and information disclosure. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - Administrators should upgrade installations affected by the listed vulnerabilities to the latest supported patch release. - GitLab issues describing security vulnerabilities will become public 30 days after the release in which they were fixed. - Patch releases are generally issued on the second and fourth Wednesdays, with urgent ad-hoc releases for critical vulnerabilities. ## Authentication and Authorization Fixes - **CVE-2026-5173 (CVSS 8.5):** Authenticated users could invoke unintended server-side methods through WebSocket connections. - **CVE-2026-2619 (CVSS 4.3):** Auditor users could modify vulnerability flag data in private projects through the AI detection API. - **CVE-2026-1752 (CVSS 4.3):** Developers could modify protected environment settings through authorization flaws in the Environments API. - **CVE-2026-2104:** CSV exports could expose confidential issues assigned to other users because of insufficient authorization checks. ## Denial-of-Service Vulnerabilities - **CVE-2026-1092 (CVSS 7.5):** Unauthenticated attackers could crash or disrupt services through malformed JSON sent to the Terraform state lock API. - **CVE-2025-12664 (CVSS 7.5):** Repeated unauthenticated GraphQL queries could cause denial of service. - **CVE-2026-1403 (CVSS 6.5):** Authenticated users could disrupt Sidekiq workers by importing malformed CSV files. - **CVE-2026-1101 (CVSS 6.5):** Authenticated users could overload GitLab through improperly validated GraphQL SBOM queries. ## Code Execution and Cross-Site Scripting - **CVE-2026-1516 (CVSS 5.7):** Crafted Code Quality report content could leak the IP addresses of users viewing the report. - **CVE-2026-4332 (CVSS 5.4):** Authenticated users could execute arbitrary JavaScript in other users’ browsers through customizable analytics dashboards. ## Information Disclosure - **CVE-2025-9484 (CVSS 4.3):** Certain GraphQL queries could reveal other users’ email addresses to authenticated users. - The release also fixes CSV export authorization issues that could expose confidential issue data. Administrators of self-managed GitLab CE or EE instances should apply 18.10.3, 18.9.5, or 18.8.9 as soon as possible, depending on their supported release branch.

Read original

GraphQL Gitlab API Cve+4

cloudflareMar 3, 20263 min readCurated summary

Evolving Cloudflare’s Threat Intelligence Platform: actionable, scalable, and ETL-less

Cloudflare’s Threat Intelligence Platform (TIP) is designed to turn massive volumes of security telemetry into actionable intelligence without relying on traditional ETL pipelines. Its sharded, SQLite-backed architecture uses Durable Objects and edge-based GraphQL to provide near-real-time analysis across millions of events. By combining automated telemetry with analyst investigations, the platform aims to help security teams understand threats and block them proactively. ## Motivation for Building the Platform - Cloudflare began developing the TIP after launching Cloudforce One in 2022 and discovering that existing tools could not adequately track adversary infrastructure. - The platform models the full threat lifecycle, connecting: - Threat actors to malware - Cases to indicators - Events to broader campaigns - It is designed for: - Multiple datasets and tenants - Group-based and tenant-to-tenant sharing - Extensibility and edge-scale performance - Visual analysis and automated response - Cloudflare Workers allow the platform to evolve with the runtime and support features such as Smart Placement, higher CPU limits, and Hyperdrive. ## Beyond the SIEM - The TIP complements rather than replaces a SIEM: - SIEMs focus on real-time log aggregation and alerting. - The TIP provides long-term retention, specialized threat schemas, and historical context. - Analysts can enrich alerts with: - Indicator history - Known threat-actor associations - Campaign relationships - Risk scores and intelligence context - Findings from analysts feed new indicators of compromise back into the platform. - This feedback loop keeps intelligence current and helps organizations move from reactive investigation to proactive defense. ## Sharded Storage Without ETL Bottlenecks - Cloudflare distributes Threat Events across many logical shards instead of using one centralized database. - Each shard is a Durable Object with a private SQLite database, providing transactional consistency and avoiding a single database bottleneck. - Cloudflare Queues handle asynchronous ingestion, helping absorb high-volume attack spikes. - R2 stores data for long-term retention, while SQLite maintains a hot index for fast access. - Because data is available directly in the platform’s operational store, complex ETL pipelines and synchronization delays are avoided. ## Parallel Queries at the Edge - GraphQL runs in the same Worker-based system that powers the Threat Events platform, keeping data live from ingestion through querying. - Queries are fanned out to relevant Durable Objects in parallel rather than executed against one large table. - The platform first verifies permissions and excludes shards that cannot contain matching events, such as shards outside the requested date range. - Results from multiple shards are aggregated with `Promise.all`, enabling low-latency searches across global datasets. - Smart Placement positions query Workers near the Durable Objects they access, reducing tail latency. Cloudflare’s approach combines edge-native storage, parallel execution, and analyst-driven enrichment to make threat intelligence both scalable and actionable. The practical goal is a unified system that explains not only what is malicious, but also why it matters and how to automatically prevent it.

Read original

GraphQL Database Design Cloudflare Workers Sqlite+4

airbnbFeb 11, 20263 min readCurated summary

My Journey to Airbnb — Anna Sulkina

Anna Sulkina’s career journey moved from hardware diagnostics and frontend development into backend infrastructure and engineering leadership. Her experiences at Twitter taught her to design distributed systems for failure and to build consensus around transformative technologies like GraphQL. She joined Airbnb in 2022 because it aligned her passion for travel with an opportunity to strengthen developer infrastructure, organizational strategy, and engineering collaboration. ## Discovering Technology in Post-Soviet Ukraine - Sulkina grew up in Eastern Ukraine as the Soviet Union collapsed. - Her older brother introduced her to computers by bringing home hardware components and assembling a machine that loaded programs from a cassette player. - Seeing how individual components formed a working system inspired her to pursue technology. ## Learning English While Building Technical Skills - She studied programming at a Ukrainian university before immigrating to the United States. - Although she understood written English and knew how to program, communicating in English was initially more difficult than learning programming languages. - She took ESL classes while studying C++ and Java through Berkeley Extension. - Her first job was in hardware diagnostics at a five-person company. - A language barrier caused her to run out of time on a technical interview, but an interviewer familiar with her Berkeley class gave her another opportunity. - She eventually transitioned from C++ to Java, which became her primary language for many years. ## Moving Down the Stack and Into Leadership - Sulkina’s career progressed from hardware diagnostics to frontend, backend, and infrastructure engineering. - At the same time, she increasingly took on leadership responsibilities. - At Caymas Systems, her manager recognized her leadership potential and showed her the difference effective leadership makes. - At Comcast, she moved from individual contributor to engineering manager. - Coaching engineers, building software collaboratively, and developing high-performing teams convinced her that leadership was the right path. ## Lessons from Twitter’s Distributed Systems - During nearly nine years at Twitter, Sulkina advanced from first-line manager to director. - She worked through major operational events, including the “fail whale” period and the tweetstorm surrounding Ellen DeGeneres’s viral selfie. - Twitter’s transition from a monolith to microservices taught her that failure is inevitable in complex systems. - Resilient distributed systems must be designed to handle failures rather than assuming failures can be prevented. - Her cultural lesson involved turning promising ideas into adopted technologies. - She helped bootstrap Twitter’s GraphQL API, replacing legacy REST services. - The effort required leadership support, cross-team consensus, and stakeholder alignment, but ultimately improved product teams’ development velocity. ## Choosing Airbnb - Airbnb contacted Sulkina in 2022, when she felt ready to move beyond a well-established organization at Twitter. - The company appealed to her because it combined her professional interests with her personal passion for travel; she had been an Airbnb guest since 2013. - Airbnb’s Developer Platform organization had strong work happening in separate silos but needed clearer strategy, direction, and trust across engineering. - Sulkina began by clarifying the organization’s purpose and future direction. - Her early priorities included strengthening the organization, coaching leaders, and creating alignment within the team and with the teams it supported. - Over the following years, this work produced a high-performing organization with clearer strategy, stronger execution, and a focus on delivering business value. Sulkina’s story emphasizes that technical growth, organizational leadership, and personal motivation can reinforce one another. Her experience suggests that successful engineering leaders design for failure, invest in alignment, and use clear strategy to turn fragmented efforts into meaningful platform-wide impact.

Read original

GraphQL Distributed Systems Microservices Java+3

metaFeb 4, 20263 min readCurated summary

No Display? No Problem: Cross-Device Passkey Authentication for XR Devices

Passkeys provide phishing-resistant authentication, but standard cross-device flows depend on QR codes displayed on the device being authenticated. This creates a problem for XR headsets, smart-home hubs, sensors, and other devices with no accessible screen. The proposed solution uses an authenticated companion app to transport the FIDO hybrid-flow request, preserving proximity, trust, and standard WebAuthn security without requiring a QR code. ## The Challenge: Screenless Devices Cannot Display QR Codes - Traditional cross-device passkey authentication uses: - A QR code displayed by the desktop or other target device. - Bluetooth or NFC to verify proximity and establish communication. - Devices without usable displays cannot show a QR code for a phone to scan. - Proximity discovery alone is insufficient because users still need a clear, secure way to approve the correct authentication request. ## Companion Apps as Secure Message Transport - The target device generates the same hybrid-flow request normally encoded in a QR code. - Instead of displaying it, the device sends the request to an authenticated companion app associated with the same user account. - In-app notifications provide a user-consent surface and direct the user into the passkey flow. - Opening the app itself can initiate the flow because the user must deliberately open it, and mobile operating systems provide an additional verification step. ## Meta Quest and Meta Horizon Implementation - The implementation is broadly available on Meta Quest devices running Meta Horizon OS. - The Quest browser creates a FIDO URL containing: - A fresh ECDH public key. - A session-specific secret. - Routing information for the hybrid handshake. - The URL is packaged as structured data in a GraphQL-based push notification. - The Meta Horizon app validates that the request belongs to the correct signed-in user before processing it. ## Notification and Deep-Link Flow - iOS or Android displays a notification that a passkey login is pending. - Tapping the notification opens the Meta Horizon app, which launches the FIDO URL through the operating system. - The OS then invokes its passkey interface. - If notifications are disabled, opening the app queries the backend for pending requests. - Requests expire after five minutes, limiting the window for misuse. - The mobile device then performs the normal hybrid transport process: - Broadcasting a BLE advertisement. - Establishing an encrypted tunnel. - Generating the passkey assertion. ## WebAuthn Challenge and Response - The inaccessible device creates the normal WebAuthn challenge and waits for a response. - The mobile authenticator initiates the secure BLE or NFC connection. - The challenge travels through the encrypted channel. - After successful user verification, the phone creates an `AuthenticatorAssertionResponse` or `AuthenticatorAttestationResponse`. - The inaccessible device forwards that response to the relying-party server just as a display-equipped device would. ## Broader Impact - The approach removes the QR-code requirement while retaining FIDO hybrid transport and proximity protections. - It could extend passwordless authentication to: - XR headsets and wearables. - Screenless IoT devices. - Smart-home hubs. - Industrial sensors and hardware. - The work builds on FIDO Alliance standards and mobile operating-system support, helping broaden interoperability across device ecosystems. The companion-app model offers a practical way to bring secure cross-device passkeys to devices that cannot display QR codes. It is especially suitable where the device already has an authenticated mobile app and can rely on standard WebAuthn, BLE/NFC proximity, and platform user verification.

Read original

GraphQL Passkeys Webauthn Iot Security+4

netflixJan 27, 20263 min readCurated summary

The AI Evolution of Graph Search at Netflix

Netflix is evolving Graph Search from structured DSL queries toward natural-language search using large language models (LLMs). The goal is to let users describe what they want in everyday language while preserving the accuracy and trustworthiness required by Netflix’s complex, federated GraphQL data. Rather than replacing existing applications, Netflix plans to augment them with AI-generated filters and future retrieval-augmented generation capabilities. ## Why Natural-Language Search Is Needed - Graph Search currently relies on a Filter DSL, with applications translating UI interactions into structured queries. - Netflix has hundreds of applications with inconsistent query-building experiences, forcing users to learn different interfaces. - Some indexes contain hundreds of filterable fields, making large forms slow and cumbersome even for subject-matter experts. - Users naturally express goals in language such as “show all movies from the 90s about robots from the US,” not through query builders or DSL syntax. - Natural-language input could reduce friction while allowing each application to retain its own domain-specific presentation. ## Converting Text into Graph Search Filters - The core task is translating an ambiguous natural-language request into a valid Graph Search Filter DSL statement. - Graph Search indexes are defined through GraphQL queries containing typed fields, including booleans, strings, enums, and controlled vocabularies. - Generated filters can combine: - Comparisons such as `>` and `==` - Inclusion or exclusion operators such as `IN` - Logical operators such as `AND` - Netflix evaluates generated queries at three levels: - **Syntactic correctness:** The statement follows the DSL grammar and can be parsed. - **Semantic correctness:** The query uses existing fields, respects field types, and selects valid controlled-vocabulary values. - **Pragmatic correctness:** The filter accurately reflects the user’s intended meaning. ## Context Engineering for the LLM - The LLM needs index metadata to generate semantically valid filters. - Netflix derives much of this context from GraphQL schemas, including: - Field paths - Field descriptions from schema comments - Field types - Valid enum or controlled-vocabulary values - Controlled vocabularies define finite, governed sets of values, such as countries, and prevent generated queries from using invalid alternatives. - Supplying all metadata works for simple examples but does not scale: - Some indexes contain hundreds of fields. - Some vocabularies contain thousands of values. - Larger prompts increase latency and can reduce generation accuracy. - Netflix therefore needs ways to provide the LLM with relevant metadata without overwhelming its context, while still grounding generated queries in the actual schema and allowed values. Netflix’s approach combines schema-aware context, LLM-based query generation, and validation to make natural-language Graph Search practical. The key recommendation is to use AI as an augmentation layer over existing Graph Search applications, with strong grounding and correctness checks rather than treating generated queries as inherently reliable.

Read original

GraphQL Large Language Models Natural Language Processing RAG+4

airbnbOct 30, 20252 min readCurated summary

GraphQL Data Mocking at Scale with LLMs and @generateMock

Airbnb’s `@generateMock` directive combines GraphQL schemas, product context, design references, and LLMs to generate realistic, type-safe mock data automatically. Integrated into the existing Niobe code-generation workflow, it reduces manual mock maintenance and helps client engineers prototype and test features before backend implementation is complete. ## Challenges with GraphQL Mocking - Manually creating large JSON responses or schema-generated objects is tedious and error-prone. - Client engineers often hardcode data or modify networking logic when the server is not yet ready, slowing frontend development. - Handwritten mocks drift out of sync as queries and schemas evolve. - Random generators and field-level resolvers lack the domain knowledge needed for convincing, meaningful data. ## Airbnb’s Goals - Eliminate hand-written mock data and ongoing maintenance. - Generate realistic data suitable for demos, snapshots, and tests. - Keep engineers in their normal local development workflow without requiring separate tools or repositories. ## The `@generateMock` Directive - Engineers can add `@generateMock` to GraphQL operations, fragments, or fields. - Optional arguments customize the generated data: - `id` identifies a mock and names generated helper functions. - `hints` provide instructions such as destinations, content, or desired density. - `designURL` links to a design mockup so generated names, addresses, and other values better match the intended UI. - The directive can be repeated with different arguments to create multiple mock variations. ## Integration with Niobe - After adding or changing `@generateMock` in a `.graphql` file, engineers run Niobe just as they would for ordinary GraphQL code generation. - Niobe generates: - JSON files containing the mock responses. - TypeScript, Kotlin, or Swift helpers for consuming the mocks. - Generated functions return instantiated, type-safe model objects for demo apps, snapshot tests, and unit tests. - Engineers can edit the generated JSON manually; Niobe preserves those changes during later generation runs. ## Context Used by the LLM Niobe supplies the LLM with information needed to create realistic results: - The mocked operations, fragments, fields, and their dependencies. - The relevant subset of the GraphQL schema and inline documentation. - Only schema types and fields needed to resolve the query, avoiding unnecessary context-window usage. - A snapshot image of the design referenced by `designURL`, generated through Airbnb’s internal design-document API.

Read original

GraphQL Large Language Models TypeScript Kotlin+4

netflixSep 22, 2025Original article

Scaling Muse: How Netflix Powers Data-Driven Creative Insights at Trillion-Row Scale | by Netflix Technology Blog | Netflix TechBlog (opens in new tab)

Netflix’s Muse platform has evolved from a simple dashboard into a high-scale Online Analytical Processing (OLAP) system that processes trillions of rows to provide creative insights for promotional media. To meet growing demands for complex audience affinity analysis and advanced filtering, the engineering team modernized the data serving layer by moving beyond basic batch pipelines. By integrating HyperLogLog sketches for approximate counting and leveraging in-memory precomputed aggregates, the system now delivers low-latency performance and high data accuracy at an immense scale. ### Approximate Counting with HyperLogLog (HLL) Sketches To track metrics like unique impressions and qualified plays without the massive overhead of comparing billions of profile IDs, Muse utilizes the Apache Datasketches library. * The system trades a small margin of error (approximately 0.8% with a logK of 17) for significant gains in processing speed and memory efficiency. * Sketches are built during Druid ingestion using the HLLSketchBuild aggregator with rollup enabled to reduce data volume. * In the Spark ETL process, all-time aggregates are maintained by merging new daily HLL sketches into existing ones using the `hll_union` function. ### Utilizing Hollow for In-Memory Aggregates To reduce the query load on the Druid cluster, Netflix uses Hollow, an internal open-source tool designed for high-density, near-cache data sets. * Muse stores precomputed, all-time aggregates—such as lifetime impressions per asset—within Hollow’s in-memory data structures. * When a user requests "all-time" data, the application retrieves the results from the Hollow cache instead of forcing Druid to scan months or years of historical segments. * This approach significantly lowers latency for the most common queries and frees up Druid resources for more complex, dynamic filtering tasks. ### Optimizing the Druid Data Layer Efficient data retrieval from Druid is critical for supporting the application’s advanced grouping and filtering capabilities. * The team transitioned from hash-based partitioning to range-based partitioning on frequently filtered dimensions like `video_id` to improve data locality and pruning. * Background compaction tasks are utilized to merge small segments into larger ones, reducing metadata overhead and improving scan speeds across the cluster. * Specific tuning was applied to the Druid broker and historical nodes, including adjusting processing threads and buffer sizes to handle the high-concurrency demands of the Muse UI. ### Validation and Data Accuracy Because the move to HLL sketches introduces approximation, the team implemented rigorous validation processes to ensure the data remained actionable. * Internal debugging tools were developed to compare results from the new architecture against the "ground truth" provided by legacy batch systems. * Continuous monitoring ensures that HLL error rates remain within the expected 1–2% range and that data remains consistent across different time grains. For organizations building large-scale OLAP applications, the Muse architecture demonstrates that performance bottlenecks can often be solved by combining approximate data structures with specialized in-memory caches to offload heavy computations from the primary database.

GraphQL Microservices Apache Spark Apache Druid+4

airbnbSep 15, 20254 min readCurated summary

Viaduct, Five Years On: Modernizing the Data-Oriented Service Mesh

Viaduct, Airbnb’s data-oriented service mesh, has evolved substantially over five years while retaining its core model: a central schema, hosted business logic, and re-entrant composition through GraphQL. Its usage has grown eightfold, supporting more than 130 teams and over 1.5 million lines of production code, without increasing operational overhead. Viaduct Modern now aims to simplify its developer API and establish stronger architectural boundaries, alongside the project’s release as open source. ## Adoption and Evolution - Viaduct traffic has increased by a factor of eight since 2020. - More than 130 teams now host code in Viaduct, supported by hundreds of weekly active developers. - The hosted codebase has grown to over 1.5 million lines, with roughly the same amount of test code. - Operational overhead has remained constant, incident-minutes have been cut in half, and costs have grown linearly with QPS. - Viaduct is now available as open-source software. ## Core Principles That Remain - **Central schema:** Viaduct provides one integrated schema connecting domains across Airbnb. - More than 75% of requests are internal. - The schema is developed by many teams but exposed as a connected graph. - **Hosted business logic:** Teams run business logic directly in Viaduct rather than maintaining separate microservices. - This reduces operational overhead and can allow standalone services to be retired. - Viaduct provides a serverless environment so developers can focus on application logic. - **Re-entrancy:** Hosted logic composes with other hosted logic through GraphQL fragments and queries. - This supports modularity. - It helps avoid the tightly coupled structure and maintenance problems associated with traditional monoliths. ## Problems with the Earlier Design - Viaduct’s APIs evolved reactively in response to individual use cases. - Multiple mechanisms emerged for accomplishing similar tasks, creating confusion for developers. - Some capabilities were well supported while others were not. - The framework’s layers had loose, inconsistent interfaces. - The boundary between Viaduct and hosted application code was weak. - These issues made framework improvements increasingly risky because changes could disrupt existing users. ## Simplifying the Tenant API - Viaduct Modern overhauls the developer-facing API and execution engine. - The new Tenant API reduces the implementation choices to two mechanisms: - **Node resolvers** - **Field resolvers** - The choice is determined by the schema rather than by ad hoc behavioral distinctions. - Resolver APIs have been unified wherever possible. - The goal is a smaller, more consistent surface that preserves successful ideas from the old API while removing unnecessary alternatives. ## Tenant Modules and Re-Entrant Composition - Viaduct uses modules and re-entrancy to provide boundaries similar to service definitions and RPC APIs in microservice architectures. - A tenant module combines: - Schema owned by a team - The code implementing that schema - Modules can create rich connections in the shared graph, but direct code dependencies between teams are discouraged. - Instead, teams declare their data requirements through GraphQL fragments and queries. ### Example: Extending the `User` Type - A Core User team owns the base `User` type and resolves fields such as `firstName` and `lastName`. - A Messaging team can extend `User` with a `displayName` field. - Its resolver declares that it needs `firstName` and `lastName`. - Messaging does not depend directly on Core User’s implementation or need to know where those fields originate. - This declarative model lets teams collaborate through the schema while preserving ownership and modularity. ## Framework Modularity - Viaduct Modern also restructures the framework itself. - The system consists of: - The GraphQL execution engine - The Tenant API - Hosted application code - Historically, the interfaces between these layers were weak, making performance and reliability improvements difficult to introduce safely. - The redesign focuses on stronger abstraction boundaries so the framework can evolve independently of application code. Viaduct’s modernization is intended to preserve its centralized, data-oriented model while making development simpler and framework evolution safer. The open-source release provides an opportunity for other organizations to evaluate or adopt this approach to schema-driven, modular service composition.

Read original

GraphQL Distributed Systems Serverless Microservices+3