Direct answer: The Android Security Bulletin for November 2026 closes 3 flaws that can run code on a phone with no user interaction: CVE-2026-58868, CVE-2026-58876, and CVE-2026-58936. Today, check the patch level of every work phone and tablet. Minimum target: 2026-11-01. Full target: 2026-11-05.

CISA gives CVSS 3.1 9.8 to CVE-2026-58876 and CVE-2026-58936. Google rates all 3 as Critical. The bulletin has 216 CVEs, and 23 are Critical by our count.

Main condition: You or your team use Android 14 to 17 phones or tablets for work. Limit: This article has no file contents, payloads, or attack sequence.

We read the Android Security Bulletin November 2026, the CVE-2026-58868 record, the CVE-2026-58876 record, the CVE-2026-58936 record, the Samsung Mobile Security page, the Pixel bulletin list, and CISA KEV on 5 November 2026, from 06.35 to 06.50 WIB. We tested 3 check scripts in a podman debian:trixie container with adb 34.0.5 from the Debian package and a stand-in adb. We did not test on a real phone, and we did not test attacks.

The problem: 1 work phone holds company accounts and data

A work phone holds customer chats, email, bank access, and cashier apps, so a flaw in the phone is a flaw in your business data.

On 2 November 2026, Google released the Android Security Bulletin for November. The most severe flaws are in the Framework and System components. The bulletin says that they can run code remotely, with no additional privileges and no user interaction.

Google releases the patch only to the Android code. The patch reaches your phone through a vendor such as Samsung, Xiaomi, OPPO, vivo, or realme. The time differs per brand and per model.

Timeline: partner notice in October, bulletin on 2 November with 216 CVEs, CISA score 9.8 on 4 November, Samsung SMR and no Pixel bulletin yet on 5 November.
Grey dots: notices and records. Red dots: the bulletin and score. Teal dot: a vendor patch. Amber dots: open items. Source: Android Security Bulletin, CVE records, CISA ADP, the Samsung Mobile Security page, and CISA KEV.

On the morning of 5 November 2026, the Samsung Mobile Security page already listed the November 2026 SMR with these 3 RCE flaws. The PixelPixelA piece of code on a web page that tells the ad platform somebody opened the page or took an action.What is the Meta Pixel? bulletin page for November 2026 was not out yet.

How it works: 3 zero-interaction RCE flaws

All 3 flaws are in code that reads media and image data. This section uses the official summaries from the CVE records, not attack steps.

CVE-2026-58868 (Framework)

The CVE-2026-58868 record says that the function onOutputReceived in FrameDecoder.cpp can write outside its memory because of a heap buffer overflow. As a result, code can run remotely with no user interaction. On 5 November 2026, this flaw has no CVSS score yet.

CVE-2026-58876 (System, Media Codecs)

The CVE-2026-58876 record says that there is a use-after-free in multiple locations. The bulletin puts this flaw in the Mainline Media Codecs component, so a Google Play system update can also carry the fix.

CVE-2026-58936 (System, libpng)

The CVE-2026-58936 record says that the function png_set_tRNS in pngset.c has a use-after-free. libpng is the library that reads PNG images. The impact is the same: remote code execution with no user interaction.

All Critical flaws in this bulletin

This table shows the 23 Critical flaws in the bulletin. Patch level 2026-11-01 closes rows 1 to 5. Patch level 2026-11-05 closes all rows.

CVEComponentTypeCVSS 3.1Closed at patch level
CVE-2026-58868FrameworkRCENone yet2026-11-01
CVE-2026-58876System (Media Codecs)RCE9.8 (CISA ADP)2026-11-01 or Google Play system update
CVE-2026-58936System (libpng)RCE9.8 (CISA ADP)2026-11-01
CVE-2026-55275, 55283, 58984SystemEoPNone yet2026-11-01
CVE-2026-58814, 58882SystemDoSNone yet2026-11-01
6 kernel CVEsBluetooth, pKVM, HIDEoP, IDNone yet2026-11-05
8 MediaTek CVEsModemRated by MediaTekNone yet2026-11-05
CVE-2026-25285Qualcomm closed-source part-None yet2026-11-05
Three red cards: CVE-2026-58868 frame decoder, CVE-2026-58876 media codecs score 9.8, CVE-2026-58936 libpng score 9.8. Safe: patch level 2026-11-05.
(1) Red cards: the 3 zero-interaction RCE flaws. (2) Amber panel: 20 other Critical flaws and the status. (3) Teal box: the safe patch level. Source: Android Security Bulletin November 2026, CVE records, and CISA ADP.

The kernel Bluetooth flaws at patch level 2026-11-05 are also important. The bulletin says that the most severe kernel flaw can raise privileges remotely with no user interaction.

Exploitation status on 5 November 2026

The bulletin shows no sign of limited, targeted attacks for any flaw. None of the 3 CVEs is on CISA KEV. The CISA assessment says "Exploitation: none", "Automatable: yes", and "Technical Impact: total". Rama Digital analysis: update before attack code appears.

Who has the highest risk

The risk depends on the patch level, the phone age, and the company data on it, not on the brand.

Device conditionRiskReason
Android 13 or olderHighestThe bulletin updates only Android 14 to 17. A patch comes only when the vendor makes one
Patch level 2026-10-05 or olderHighThe 3 RCE flaws stay open
Work phones with email, customer chats, and bank appsHigh1 broken phone opens company accounts and data
Cashier tablets, courier phones, or shared phones without MDMCheckThese devices often miss updates for months
MediaTek or Qualcomm chipsCheckModem and chip flaws close only at patch level 2026-11-05
Patch level 2026-11-05LowStill look for signs from the time before the update
Six risk cards: Android 13 and older, October patch and older, and work phones are red; cashier tablets and MediaTek or Qualcomm chips are amber; patch 2026-11-05 is grey.
Red cards: the highest risk. Amber cards: check. Grey card: low risk. Bottom box: the exploitation status on 5 November 2026. Source: Android Security Bulletin, CISA ADP, CISA KEV, and Rama Digital analysis.

Your servers need their own patches too, for example for the Linux kernel TCP flaw CVE-2026-98432. Other critical warnings from this week: the WordPress CVE-2026-119977 warning, the pgAdmin 4 CVE-2026-116241 warning, and the Puppet CVE-2026-115731 warning.

Patch level and device status

The bulletin uses 2 patch levels, so 1 phone can be safe from the 3 RCE flaws but not yet safe from kernel and chip flaws.

Patch level on the deviceClosesStatusAction
2026-11-05 or laterAll 216 CVEs in this bulletinSAFEGo to step 5
2026-11-01 to 2026-11-04119 CVEs, with the 3 RCE flawsPARTIALWait for patch 2026-11-05, apply step 4b
2026-10-05 or olderNo November patch yetVULNERABLEUpdate this week, apply step 4
Android 13 or older with no November patchNot on the list of updated AOSP versionsNO PATCHReplace the device or remove company data access
A patch level table: 2026-11-05 safe, 2026-11-01 partial, 2026-10-05 and older vulnerable, Android 13 and older no patch, Google Play system update as an extra.
Teal: safe. Amber: partial or extra. Red: vulnerable or no patch. Bottom box: 2 ways to check the patch level. Source: the patch level FAQ in the Android Security Bulletin November 2026 and Rama Digital analysis.

The FAQ in the Android Security Bulletin November 2026 says that a device with patch level 2026-11-01 must include all fixes at that level. A device with 2026-11-05 must include all fixes in this bulletin. Rama Digital analysis: we mark Android 13 and older with an old patch as NO PATCH, because those versions are not on the list of updated AOSP versions.

The Google Play system update changes Mainline components, with Media Codecs for CVE-2026-58876. This update does not replace the vendor system update, because the other 2 RCE flaws are outside Mainline.

Before you start

  • A list of work phones and tablets, with the holder name and the model.
  • Access to the MDM console when the company uses MDM.
  • For checks from a computer: Android platform-tools (adb) and a USB cable. Follow the Google adb documentation to turn on USB debugging.
  • Wi-Fi and a battery above 50 percent for the update. An update can be hundreds of MB.
  • A backup of important chats and photos before the update.

Step 1: Check the patch level of every phone

The fastest way for 1 phone: open Settings, then About phone, then Android version. Read the Android security update line. Menu names differ per brand, so search for "update" or "security" in Settings.

For many phones at 1 desk, save this script as check-patch-android.sh. The script reads the Android version and the patch level of every phone that adb can see.

#!/usr/bin/env bash
# Check the Android security patch for the November 2026 bulletin (CVE-2026-58868, CVE-2026-58876, CVE-2026-58936).
# The script only reads. No arguments: read every phone that adb can see.
# With arguments: check values that you copied from Settings, format <Android version>:<patch level>.
# Example: bash check-patch-android.sh 16:2026-10-01 15:2026-11-01 14:2026-11-05 13:2026-08-01
set -u
FULL=2026-11-05
PARTIAL=2026-11-01

verdict() { # $1 Android version, $2 patch level YYYY-MM-DD
  local rel=$1 spl=$2 major=${1%%.*}
  if ! [[ $spl =~ ^[0-9]{4}-[0-9]{2}-[0-9]{2}$ ]]; then
    echo "CHECK: cannot read the patch level"; return
  fi
  local old=0
  [[ $major =~ ^[0-9]+$ ]] && (( major <= 13 )) && old=1
  if [[ ! $spl < $FULL ]]; then
    echo "SAFE for the November 2026 bulletin"
  elif [[ ! $spl < $PARTIAL ]]; then
    echo "PARTIAL: 3 RCE flaws closed, kernel and chip flaws wait for patch $FULL"
  elif (( old )); then
    echo "NO PATCH: Android $rel is not on the AOSP list. Replace or limit this device"
  else
    echo "VULNERABLE: update to patch $PARTIAL or later"
  fi
}

if (( $# > 0 )); then
  for x in "$@"; do
    printf '%-12s patch %-11s -> %s\n' "Android ${x%%:*}" "${x#*:}" "$(verdict "${x%%:*}" "${x#*:}")"
  done
  exit 0
fi

command -v adb >/dev/null || { echo "adb is missing. Install Android platform-tools, or check in the phone Settings."; exit 1; }
mapfile -t phones < <(adb devices | awk 'NR>1 && $2=="device" {print $1}')
(( ${#phones[@]} )) || { echo "No phone is connected. Turn on USB debugging, then allow this computer on the phone."; exit 1; }

for s in "${phones[@]}"; do
  p() { adb -s "$s" shell getprop "$1" </dev/null | tr -d '\r'; }
  rel=$(p ro.build.version.release)
  spl=$(p ro.build.version.security_patch)
  echo "$(p ro.product.manufacturer) $(p ro.product.model) | Android $rel | patch $spl"
  echo "  -> $(verdict "$rel" "$spl")"
done
# Manual check with adb, for 1 phone
adb devices
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch
# Script: read every connected phone
bash check-patch-android.sh
# Script: check values that you copied from the Settings of other phones
bash check-patch-android.sh 16:2026-10-01 15:2026-11-01 13:2026-08-01
Terminal: with no phone the script says no phone. With 3 dummy phones: Samsung PARTIAL, Xiaomi VULNERABLE, OPPO Android 13 NO PATCH. Manual mode: 6 values.
The first command uses the real adb with no phone. The second command uses a stand-in adb with 3 dummy phones. The third command uses values typed by hand. Source: Rama Digital test in a podman debian:trixie container with adb 34.0.5 from the Debian package and a stand-in adb, 5 November 2026.

The script reads only 3 system properties. It installs nothing and changes no phone setting.

Check the result: "VULNERABLE" or "NO PATCH" means go to steps 3 and 4 today. "PARTIAL" means the 3 RCE flaws are closed, but apply step 4b until patch 2026-11-05 arrives.

Step 2: Check the fleet from an MDM export

When you have more than 10 devices, use the list from MDM or the inventory, not a check of each device.

Export the device list from MDM to CSV. Make sure that it has an Android version column and a patch level column. Save this script as check-fleet-android.py.

#!/usr/bin/env python3
"""Check an Android fleet from an MDM CSV export or an inventory list for the November 2026 bulletin.

The script only reads the CSV file. It finds the columns from their headings:
device name (first column), Android version ("android", "os", or "version"), and patch level ("patch").
Example: python3 check-fleet-android.py mdm-export.csv
"""
import csv
import re
import sys
from collections import Counter

FULL, PARTIAL = '2026-11-05', '2026-11-01'


def column(heads, *words):
    for i, h in enumerate(heads):
        if any(w in h.lower() for w in words):
            return i
    return None


def verdict(rel, spl):
    if not re.fullmatch(r'\d{4}-\d{2}-\d{2}', spl):
        return 'CHECK'
    major = re.match(r'\d+', rel)
    if spl >= FULL:
        return 'SAFE'
    if spl >= PARTIAL:
        return 'PARTIAL'
    if major and int(major.group()) <= 13:
        return 'NO PATCH'
    return 'VULNERABLE'


with open(sys.argv[1], newline='', encoding='utf-8-sig') as f:
    rows = list(csv.reader(f))
heads, data = rows[0], [r for r in rows[1:] if any(r)]
c_patch = column(heads, 'patch')
c_rel = column(heads, 'android', 'os', 'version')
if c_patch is None or c_rel is None:
    sys.exit('No patch level or Android version column. Check the CSV headings.')

count = Counter()
for r in data:
    status = verdict(r[c_rel].strip(), r[c_patch].strip())
    count[status] += 1
    if status != 'SAFE':
        print(f'{status:<12} {r[0]:<22} Android {r[c_rel].strip():<5} patch {r[c_patch].strip()}')
print(f'\nTotal {len(data)} devices: ' + ', '.join(f'{s} {count[s]}' for s in ('SAFE', 'PARTIAL', 'VULNERABLE', 'NO PATCH', 'CHECK')))
print(f'Target: patch {PARTIAL} this week, patch {FULL} when the vendor releases it.')
python3 check-fleet-android.py mdm-export.csv
Terminal: the fleet script reads 10 devices from a CSV file and prints SAFE 2, PARTIAL 2, VULNERABLE 4, NO PATCH 2, then the patch target.
The list of 10 devices is dummy data with columns like an MDM export. Source: Rama Digital test in a podman debian:trixie container with adb 34.0.5 from the Debian package and a stand-in adb, 5 November 2026.

Without MDM, make your own CSV from step 1: 1 row per device with the name, model, Android version, and patch level.

Check the result: write down the VULNERABLE and NO PATCH counts. Send the device names to their holders today, with an update deadline.

Step 3: Install the system update and the Google Play system update

Only the system update closes these flaws. The phone uses the new code only after a restart.

  1. Open Settings, then the system update or software update menu. Download and install the update. Follow the Google Android update guide.
  2. Open the Google Play system update menu. On many phones, this menu is in the Security or About phone section. Install the update.
  3. Restart the phone.
  4. Run step 1 again. The correct result: "PARTIAL" or "SAFE".

When the update menu says that the phone is up to date but the patch level is still October, the vendor has no patch for that model yet. Check again every 2 to 3 days, and apply step 4 until the patch arrives.

3b. MDM rule: a minimum patch for company data

In MDM, make a compliance rule with a minimum patch level of 2026-11-01. Devices below the line lose access to company email and chat until the holder updates. Microsoft Intune has the setting "Minimum security patch level" for this rule.

Give 7 days before the rule starts. Many vendors release patches in stages per model.

A 7-row ladder: check the patch level, check the fleet, system update, MDM rule, 2 steps labelled not a fix (media auto-download, Bluetooth), then signs.
(1) to (3b): the fix order. (4a) and (4b): temporary steps. The red labels remind you that only the system update closes the flaws. Source: Android Security Bulletin, the Google Android update guide, and Rama Digital analysis.

Check the result: the step 1 script prints "PARTIAL" or "SAFE", and the MDM report shows 0 devices below 2026-11-01 after the deadline.

Step 4: Lower the risk until the patch arrives

These steps lower the chance of an attack, but they do not close the flaws.

Rama Digital analysis: the 3 RCE flaws are in code that reads media and images. Condition: no patch is available for your phone yet. Limit: other apps and previews can still process images, so these steps do not make the phone safe.

4a. Turn off media auto-download in chat apps

In WhatsApp, open Settings, then Storage and data. In the media auto-download section, turn off all media types for mobile data, Wi-Fi, and roaming. Do the same in Telegram and other chat apps.

With this setting, the phone does not download and process photos or videos from unknown numbers before you choose them. Do not open media from senders that you do not know.

4b. Turn off Bluetooth when you do not use it

The kernel Bluetooth flaws close only at patch level 2026-11-05. Turn off Bluetooth from the quick panel when you do not use earphones, a receipt printer, or a smart watch.

4c. Remove company data from Android 13 and older

Remove company email and chat accounts from NO PATCH devices. Use those devices only for tasks without customer data, then plan a replacement this month.

Check the result: auto-download is off on every work phone, and NO PATCH devices have no company accounts.

Step 5: Find items to check

Google published no attack signs for these 3 flaws, so look for changes that the phone holder does not know.

Save this script as check-signs-android.sh. The script reads the crash buffer, new third-party apps, accessibility services, device admin apps, and the permission to install apps.

#!/usr/bin/env bash
# Find items to check on 1 Android phone after the November 2026 bulletin. The script only reads.
# Google published no attack signs for these 3 RCE flaws. So the script writes CHECK, not proof of an attack.
# Usage: bash check-signs-android.sh [start date YYYY-MM-DD]
set -u
START=${1:-2026-10-01}
command -v adb >/dev/null || { echo "adb is missing. Install Android platform-tools."; exit 1; }
s=$(adb devices | awk 'NR>1 && $2=="device" {print $1; exit}')
[ -n "$s" ] || { echo "No phone is connected."; exit 1; }
a() { adb -s "$s" shell "$@" </dev/null | tr -d '\r'; }
checks=0
show() { # $1 section title, $2 content (1 item per line)
  echo "$1"
  if [ -n "$2" ]; then
    echo "$2" | sed 's/^/   CHECK /'
    checks=$((checks + $(echo "$2" | wc -l)))
  else
    echo "   None"
  fi
}

crash=$(a logcat -b crash -d | grep -oE '>>> [^ ]+ <<<|Process: [^ ,]+' \
  | sed -E 's/^>>> (.*) <<<$/\1/; s/^Process: //' \
  | grep -iE 'media|codec|extractor|png|surfaceflinger|gallery|photo|whatsapp' | sort | uniq -c | awk '{print $2" ("$1"x)"}')
show "1. Crashes of media and image processes (crash buffer)" "$crash"

new=""
while read -r pkg inst; do
  [ -n "$pkg" ] || continue
  t=$(a dumpsys package "$pkg" | grep -m1 -oE 'firstInstallTime=[0-9-]+' | cut -d= -f2)
  [[ -n $t && ! $t < $START ]] || continue
  [ "$inst" = com.android.vending ] && from="Play Store" || from="outside Play Store ($inst)"
  new+="$pkg installed $t from $from"$'\n'
done < <(a pm list packages -3 -i | sed -E 's/^package:([^ ]+) +installer=(.*)$/\1 \2/')
show "2. Third-party apps installed since $START" "${new%$'\n'}"

acc=$(a settings get secure enabled_accessibility_services | tr ':' '\n' | grep -v '^null$' | grep -v '^$')
show "3. Active accessibility services" "$acc"

adm=$(a dumpsys device_policy | grep -oE 'ComponentInfo\{[^}]+\}' | sort -u | sed -E 's/ComponentInfo\{(.*)\}/\1/')
show "4. Device admin apps" "$adm"

src=$(a appops query-op REQUEST_INSTALL_PACKAGES allow 2>/dev/null | grep -v '^$')
show "5. Apps that can install other apps" "$src"

echo
echo "CHECK $checks. Each CHECK line needs an explanation from the phone owner."
echo "No CHECK line is not proof of safety. The patch level stays the main check."
bash check-signs-android.sh 2026-10-01
Terminal: the signs script prints CHECK 7: 2 media processes crashed, 1 app from outside Play Store, 1 accessibility service, 1 admin, 2 installer apps.
All apps and crashes come from a stand-in adb. The test had no attack and no real phone. Source: Rama Digital test in a podman debian:trixie container with adb 34.0.5 from the Debian package and a stand-in adb, 5 November 2026.
Two columns: on the phone with adb (media crashes, apps from outside Play Store, accessibility, admin) and in accounts (linked devices, Google sessions, Play Protect, battery).
Amber column: checks with adb. Red column: checks in accounts and apps. Bottom box: the steps when you find even 1 sign. Source: Google adb documentation, Android Security Bulletin, and Rama Digital analysis.

The crash buffer on a phone keeps only recent data. So an empty section 1 does not prove that no crash ever occurred.

Check the accounts too: linked devices in WhatsApp, sessions on the Google account, and Google Play Protect warnings. Phishing messages often come after a phone breach, so warn your team.

Check the result: every CHECK line has an explanation from the phone holder. Example: the admin app is the company MDM agentAI agentAn AI program that performs work steps by itself, for example reading a message, drafting a reply, and recording the result.Open the glossary.

When 1 sign has no explanation, remove the phone from company email and chat. Change passwords from another device, sign out unknown linked devices, then update. When the sign stays, back up the data and do a factory reset.

When the phone holds customer data, Indonesian Law 27/2022 on Personal Data Protection requires a written notice within 3 times 24 hours after a personal data breach.

Example: 1 morning for 10 shop devices

This simulation uses the dummy data from step 2. The device names and results are not customer data.

Time (WIB)Dummy devicesResultAction
08.00All 10 devicesSAFE 2, PARTIAL 2, VULNERABLE 4, NO PATCH 2Send the list to the holders
08.30kasir-02, kurir-01, kurir-02, owner-01VULNERABLESystem update and restart. owner-01 has no patch yet, so step 4
09.00kurir-03, gudang-01 (Android 13)NO PATCHRemove company accounts, plan a replacement
09.30kasir-03, sales-01PARTIALStep 4b, check for patch 2026-11-05 next week
10.00All work phonesMedia auto-download offStep 5 on phones with customer data

The lesson from the simulation: 6 of 10 devices cannot be safe today. Step 4 and the MDM rule protect company data until the patch arrives.

Who installs the patch

The update duty differs per device type, so this table helps you know who acts today.

Device typePatch ownerYour work
Company phones with MDMThe IT team, through MDMSteps 2, 3b, and 5
Personal phones used for workThe phone ownerAsk for proof of the patch level, then step 4a
Cashier tablets from a point-of-sale vendorThe vendor, per the contractAsk for a written update plan and the patch level
Android 13 or older devicesNo AOSP patchStep 4c and a replacement plan

Rama Digital advice: put the patch level on your monthly checklist, the same as backups. Google releases an Android bulletin every month.

Checklist for today

  1. List all work phones and tablets. Owner: the IT team or the business owner. Proof: a list of names, models, and holders.
  2. Check the patch level with step 1 or 2. Owner: the IT team. Proof: the script output.
  3. Install the system update and the Google Play system update, then restart. Owner: the device holder. Proof: the new patch level.
  4. Set the MDM rule with a minimum patch of 2026-11-01. Owner: the IT team. Proof: the compliance report.
  5. Turn off media auto-download and unused Bluetooth. Owner: the device holder. Proof: a screenshot of the settings.
  6. Remove company accounts from NO PATCH devices. Owner: the IT team. Proof: the list of removed devices.
  7. Look for signs with step 5 on phones with customer data. Owner: the IT team. Proof: the script output and an explanation for each CHECK.

Questions and answers

Are attackers using these flaws now?

On 5 November 2026, the bulletin shows no attacks, and none of the 3 CVEs is on CISA KEV. CISA rates all 3 flaws as automatable, so update before attack code appears.

My phone has patch 2026-11-01. Is it safe?

It is safe from the 3 RCE flaws in this article. The kernel, MediaTek modem, and Qualcomm flaws close only at 2026-11-05, so apply step 4b until that patch arrives.

My phone has no update yet. What do I do?

Apply step 4, then check the update menu every 2 to 3 days. Vendors release patches in stages per model and per country.

Does the Google Play system update alone close these flaws?

No. This update can close CVE-2026-58876 in the Media Codecs component. CVE-2026-58868 and CVE-2026-58936 need the vendor system update.

My phone runs Android 13. Is it affected?

The bulletin rates only Android 14 to 17. Rama Digital analysis: treat Android 13 as at risk, because the media and libpng code is also in old versions and no more AOSP patches come.

Can antivirus software close these flaws?

No. These flaws are in the Android system code. Antivirus software and Google Play Protect can find harmful apps, but they do not patch system code.

Do the check scripts change anything on my phone?

No. The 3 scripts only read system properties, the app list, settings, and the crash buffer. Only steps 3 and 4 change something.

Next step

The limits that stay: step 4 does not close the flaws, and an update does not remove access that an attacker already used. When you need help to audit the devices and apps that hold customer data, use Vibe Code Rescue. For 1 urgent problem today, book a 30-minute session.

Sources