Captivo Access sürüm notları — 2026 · Sayfa 1 / 13

Güvenlik

• Captivo Access'in üzerinde çalıştığı web altyapısı güncellendi. Altyapıda, saldırganın sunucuda kod çalıştırmasına izin verebilecek iki kritik açık ve özel hazırlanmış isteklerle servisi meşgul edebilecek bir açık vardı. Access artık düzeltilmiş sürümde çalışıyor; yardımcı bir kütüphanedeki küçük bir adres ayrıştırma zayıflığı da kapatıldı. Sizin için bir şey değişmiyor.

2.9.0 sürümünde neler var

Bir kişi Captivo hesabının e-posta adresini değiştirdiğinde çalışma alanındaki kullanıcısı anında yeni adrese taşınıyor (oturumları kapanır, bir sonraki giriş yeni adresle olur). Yeni adres çalışma alanında başka bir kullanıcıya aitse hiçbir şey değişmez ve merkeze bildirilir. Yalnız Captivo kurumuna ait kullanıcılar etkilenir; passkey ve dizinden yönetilen hesaplar ile self-hosted kurulumlar etkilenmez. Şema değişikliği ve yeni yapılandırma yok.

2.8.0 sürümünde neler var

Captivo hesabından tek çıkış: oradan çıkış yapmak (ya da orada şifre veya iki adım sıfırlamak) artık kişinin çalışma alanındaki oturumlarını da aynı anda kapatıyor. Yalnız Captivo kurumuna ait kullanıcılar etkilenir; passkey ve dizinden yönetilen hesaplar ile self-hosted kurulumlar etkilenmez. Şema değişikliği ve yeni yapılandırma yok.

2.7.0 sürümünde neler var

Captivo kurumundaki değişiklikler artık çalışma alanına anında ulaşıyor.

• Captivo hesap sayfasında bir üye çıkarıldığında ya da rolü değiştiğinde çalışma alanı bunu hemen uyguluyor: çıkarılan üye pasife alınıp her yerden çıkış yaptırılıyor, rolü değişen üye bir sonraki isteğinde yeni rolüyle devam ediyor. Şimdiye kadar çalışma alanı bunu kişinin bir sonraki girişinde öğreniyordu; bildirim ulaşamazsa yine öyle öğrenir.

Yalnız Captivo kurumuna ait kullanıcılar etkilenir; passkey ve dizinden yönetilen hesaplara dokunulmaz. Self-hosted kurulumlar etkilenmez. Şema değişikliği ve yeni yapılandırma yok.

2.6.0 sürümünde neler var

Captivo hesabınızdaki kurum rolü artık çalışma alanını her girişte yönetiyor.

• Roller için tek kural: kurumda Sahip ya da Yönetici olan çalışma alanına Admin, Üye olan Staff olarak gelir. Birinin rolünü Captivo hesap sayfasında değiştirin; bir sonraki girişinde çalışma alanına yansır. Çalışma alanı rolü yalnızca daraltabilir (bir kurum yöneticisini Operatör ya da Denetçi yapabilirsiniz); kurumda Üye olan biri çalışma alanında Admin yapılamaz, kurum üyesi hiçbir zaman Vendor olmaz.
• Kurumdan ayrılma: Captivo hesap sayfasından çıkardığınız kişi çalışma alanına giremez ve pasife alınır.
• Kullanıcılar ve davetler: Captivo kurumuna ait kullanıcılar listede "Captivo ID" olarak işaretli; durumları kurumu izler, rol seçimi kurum rolünün izin verdiği kadar. Captivo kurumuna bağlı bir çalışma alanında Davetler sayfası yalnızca vendor davet eder (passkey ile giriş, Captivo hesabı yok) ve kurum üyeleri için Captivo hesap sayfasını gösterir.

Captivo kurumuna bağlı olmayan çalışma alanları, passkey hesapları ve dizinden yönetilen hesaplar etkilenmez. Şema: kullanıcı tablosunda yeni bir boş bırakılabilir sütun; migrate adımı uygular. Yeni yapılandırma yok.

2.5.1 sürümünde neler var

• Düzeltme: 2.5.0 ile gelen hesap özeti ucu her çalışma alanı için "bulunamadı" diyordu; Captivo hesap sayfasındaki Access kartı artık canlı satırını alıyor.

2.5.0 sürümünde neler var

• Yeni: Captivo hesap sayfanız (Captivo ID 1.5.0) Access kartında artık canlı bir satır gösteriyor: çalışma alanının adı, kaç site ve connector'ı olduğu, kaç connector'ın çevrimiçi olduğu, son 24 saatin oturumları ve son etkinlik. Çalışma alanı hesap sayfasına kendi adresinden, ortak servis sırrıyla ve yalnız bağlı olduğu kurum için cevap verir; konsolda başka bir şey değişmiyor.

2.4.0 sürümünde neler var

• Değişti: bulutta yeni çalışma alanı açmak artık Captivo hesabınızın kayıt formunda yapılıyor (Captivo ID 1.4.0). Tek form, tek doğrulama bağlantısı; doğruladıktan sonra Captivo ile giriş yaparsınız ve çalışma alanınız ilk gelişinizde eskisi gibi kurulur. Var olan çalışma alanları, davetler ve giriş yolları değişmedi; Captivo ID olmayan bir kurulum kendi kayıt formunu kullanmaya devam eder.

2.3.0 sürümünde neler var

• Yeni: kurum üyesi girişte çalışma alanına katılır. Captivo hesap sayfasından (Captivo ID 1.2.0) kurumunuza davet ettiğiniz biri, Captivo ile ilk girişinde artık çalışma alanınıza kurumun verdiği rolle düşer: kurumda sahip ya da yönetici ise Admin, üye ise Staff. Daha önce "hesap yok" diye geri çevriliyordu. Bu yalnız kendi konsolunuzda, yalnız Captivo girişiyle (kiracı kimlik sağlayıcısı etkilenmez) ve çalışma alanının iki adım koşulu denetlendikten sonra olur.

Şema değişikliği yok. pull ve up -d ile yükseltin; migrate adımı bir şey yapmaz.

2.2.0 sürümünde neler var

Bir çalışma alanı, konsoluna giren herkesten iki adımlı doğrulama isteyebilir.

• Eklendi: Policy sayfasında Require two-step verification. Açıkken, kimlik sağlayıcı ikinci bir adımı onaylamadıysa (Captivo ID ya da kendi sağlayıcınızla tek kullanımlık kod; Entra, Okta ve Auth0 bunu bildirir) veya pasış anahtarı kişiyi PIN, parmak izi ya da yüzle doğrulamadıysa konsol girişi reddedilir. Bir sonraki girişten itibaren geçerlidir; açık oturumlar kapatılmaz.
• Eklendi: her oturum nasıl açıldığını kaydeder, Sessions sayfası gösterir: Two-step, Passkey, Password. Bu sürümden önceki oturumlarda tire görünür.
• Değişti: ikinci adım olmadan gelen bir Captivo ID girişi önce bir kez prompt=login ile geri gönderilir; kişi doğrulayıcı kurmadan önce şifreyle açılmış bir oturum, az önce yerine getirdiği kural yüzünden reddedilmek yerine kodla yeniden doğrulanır.
• Değişti: kuralı açmak, sizin o anki girişiniz kuralı geçmiyorsa reddedilir; kimse kendisinin geçemeyeceği bir anahtarla çalışma alanını kilitleyemez.

Şema değişikliği: iki eklemeli sütun (Session.amr, SessionPolicy.requireSecondFactor), migrate adımı uygular. pull ve up -d ile yükseltin.

Captivo ID değişmedi: 1.1.0'dan beri her girişe amr damgası basıyor; bu sürüm Access'in onu okumasıdır.

2.1.5 sürümünde neler var

Bir bakım sürümü: üretim bağımlılıklarının haftalık güvenlik denetimi yeniden temiz.

• Değişti: Next.js 16.3.5 → 16.3.8 (aynı yama hattı). Aralarında SSG/ISR önbellek zehirlenmesi ve meta veri görsel rotalarında bilgi sızması olan yedi uyarıyı kapatır.
• Değişti: nodemailer 9 → 10, beş uyarıyı kapatır. Manager'ın tek kullanımı, yapılandırdığınız SMTP sunucusundan gönderim, değişmedi.
• Değişti: sharp ve source-map-js bağımlılık ağacı üzerinden yamalı sürümlere sabitlendi.
• Değişti: pazartesi denetimi başarısız olduğunda e-postanın yanında Slack'e de bildirir; kırmızı denetim olduğu hafta görülür.

Şema değişikliği yok. pull ve up -d ile yükseltin; migrate adımı bir şey yapmaz.

2.1.4 sürümünde neler var

• Değişti: oturum kayıtları artık 500 MiB'de durmuyor. Bu sınır, kayıtların kontrol düzleminin kendi diskinde tutulduğu dönemden kalmıştı; 2.1.0'dan beri kayıtlar sizin connector'ınızda duruyor, yani koruduğu disk boyutlandırmasını sizin yaptığınız disk ve oturum bitmeden sessizce kesilen bir kayıt, önlemek istediği dolu diskten daha kötü bir sonuçtu. Bir kayıt artık oturum ne kadar sürerse o kadar sürer. Connector diskini sınırlayan, Policy'deki saklama süresi ve oturumlarınızın tipik uzunluğudur.
• Eklendi: isteyen operatör için isteğe bağlı sınır. Veri düzleminde RECORDING_MAX_BYTES verildiğinde sınıra ulaşan kayıt yalnızca kısa kalmaz, işaretlenir: listede "cut short" etiketi görünür, oynatıcı tekrarın oturumdan önce bittiğini söyler. Değişken verilmezse sınır yoktur. Yeni davranış için bir şey yapmanız gerekmez; şema değişikliği bir sonraki migrate çalışmasında uygulanır.

2.1.3 sürümünde neler var

• Düzeltildi: oturum kaydını silmek sonsuza kadar askıda kalabiliyordu. Konsol silme isteğini kabul ediyor, ancak istek kaydın baytlarını tutan connector'a hiç ulaşmıyordu; girdi de süresiz duruyordu. Silmeler artık connector'a anında iletiliyor, connector'ın onayı atılmak yerine işleniyor ve düzenli bir eşitleme turu, o sırada çevrim dışı olan connector'ın silme işlerini yeniden deniyor — yani sildiğiniz bir kayıt, connector'a erişilebildiği anda gerçekten yok oluyor.

2.1.2 sürümünde neler var

• Düzeltildi: platform konsolunun telefonda kullanılabilir bir gezinmesi yoktu. 900 pikselin altında altı bölüm (Genel Bakış, Kiracılar, Etkinlik, Yöneticiler, İşler, Ayarlar) yerlerine hiçbir şey konmadan kayboluyordu; artık bunları açan bir menü düğmesi var.
• Düzeltildi: kimlik sağlayıcınız üzerinden giriş yaparken, İngilizce bir konsolda bile giriş formu Türkçe görünebiliyordu. Access artık kimlik sağlayıcıya formu İngilizce göstermesini açıkça bildiriyor.

A follow-up to 2.1.0, fixing something that release introduced.

Large file uploads to an isolated browser work again

2.1.0 gave each admin action a time window that outlasts what it waits for. For isolated-browser file uploads the two numbers disagreed: the transfer was allowed five minutes, the window around it was thirty seconds. Any upload slower than thirty seconds failed.

Uploads no longer run inside that window at all. Permission is checked first, in its own brief step, and the transfer then runs with nothing holding it — which is the only arrangement that works for a transfer that can legitimately take minutes.

If you tried a large upload on 2.1.0 and it failed part-way, this is why.

Long operations are now visible in the log

Some admin actions hold a database connection while they wait on one of your systems. That is fine at the scale this is designed for, and it is the kind of thing that stops being fine quietly. The server now records when an operation holds one for an unusually long time, so the question can be answered with measurements instead of assumptions.

Nothing to configure; it appears in the server log only when it happens.

Upgrading

Manager only. Connectors need no change.

Admin actions that reach out to your own systems no longer fail for the wrong reason.

"Test" buttons stop failing on slow-but-working systems

Testing a directory server, probing a site, sending a test email, verifying a domain, signing in through your identity provider — all of these reach a machine on your side, and all of them were being cut off after five seconds. Not because the test had failed, but because of an internal limit that had nothing to do with the test.

The clearest case: the directory test gives your domain controller twelve seconds to answer a bind and search, which is a sensible allowance. A controller measured answering in 6.6 seconds — comfortably inside that allowance — failed every single time. What you saw was a directory that did not work. What was actually happening was a probe being stopped six seconds early.

Twenty-two admin actions were affected: directory tests, site probes, domain verification, SMTP tests, the OIDC sign-in callback, isolated-browser file transfers, session replay, connector repair and log-level changes, invitations, grant decisions and access requests. Each now gets a window that outlasts what it is waiting for.

Requests can no longer hang forever

The flip side. Twenty outbound calls had no limit of their own at all — a connector that accepted the connection and then went quiet could hold a request open indefinitely. Mail sending had the same gap, in three different places, as did every DNS lookup.

Each now has its own limit, chosen for what it is waiting on. Downloads are treated differently on purpose: only the wait for the first response is limited, so a large recording or file is never cut off part-way — a truncated download looks like a corrupt file, not like a timeout.

Sending mail was the most consequential: a mail relay that stalled used to hold an invitation or an access decision open with no end, and the person waiting had no end either.

Upgrading

Manager only. Connectors need no change.

If you have an admin test that has been failing against a system you believe is healthy, it is worth trying again after this upgrade.

One fix, to a warning that was telling you the opposite of the truth.

"Background jobs haven't run yet" was wrong

The system page reported that scheduled jobs had never run — on installations where they were running every few minutes. Each job records a heartbeat when it runs, and those heartbeats were being written from outside the tenant's own data scope, so the database refused them and the failure was silently ignored.

Two consequences, and the second is the worse one: the page showed a warning that did not apply, and it could never show the warning that does. The genuine "some scheduled jobs look stopped" message only appears once the scheduler's own heartbeat looks healthy — which it never did — so a job that really had stopped would have gone unreported.

Heartbeats now land, the false warning is gone, and a real stalled job will be named.

This was found while verifying the site-health fix in 2.0.4: confirming that the job had run at all meant reading container logs, because the console could not answer the question.

Upgrading

Manager only. Connectors need no change.

Two reliability fixes. Nothing to change on your side; no visible difference to the console.

Site health results are no longer lost when a site is slow

The hourly health check probes each of your sites and records whether it answered. Those probes were running inside a single database transaction with a five-second budget — so if one site was slow to respond, the budget ran out and the whole round's results were never recorded. On the console, that looks like health information that quietly stops updating, which is the opposite of what a monitoring feature should do when something is wrong.

The check now reads its list, probes the sites, and records the results as three separate steps. A site that takes a minute to time out now simply gets marked unreachable, which is the answer you wanted.

The same applies to the notifications a health change triggers: a slow mail server can no longer cost you the health result it was reporting on.

Releases no longer depend on Google Fonts being reachable

The four typefaces the console uses were downloaded from Google every time this product was built, which meant a build could fail for reasons that had nothing to do with the code — and the error it produced pointed at the code, not the network. It cost two of six builds on 27 September.

The typefaces now ship with the product. The console looks exactly as it did: the same files, the same weights, verified against the previous output. For self-hosters this also means building from source needs no outbound connection for fonts.

All four are licensed under the SIL Open Font Licence; the licence and per-family attribution ship alongside them.

Upgrading

Manager only. Connectors need no change; 2.0.1 and newer stay compatible.

Disk housekeeping that was not happening. No change to access, recording or replay.

Upgrading a connector now reclaims its own disk

The connector install/update command the console generates has always included a cleanup step, but it ran first — before the new images were pulled, while the images it was meant to remove were still in use. So every upgrade left its replaced images on disk and tidied up the previous upgrade's instead, one release behind. On a host upgraded twice, 1.5 GB was sitting there until someone cleaned it by hand.

The cleanup now runs last, after the new containers are up, and reclaims what that upgrade just replaced.

It is also limited to Captivo Access images. Before, it removed every unused image on the machine, including ones belonging to other software you run on the same host. If your connector shares a host with anything else, that command no longer touches it.

Nothing to do differently — copy the command from the connector's page as usual.

The documented server upgrade now reclaims disk too

docker compose pull + up -d leaves the replaced version on disk, and unlike the connector's images those keep their version tag, so an ordinary cleanup command skips them entirely. Thirteen unused images had accumulated on one server, the database-migration image alone weighing 1.05 GB per version.

The update instructions now include the cleanup step that actually reaches them, with a note on what it will and will not remove: the version you are running is always kept; the previous one is removed, so going back means downloading it again.

Upgrading

Manager and connector can move independently; neither is required by the other for this release.

A correction to what the recordings list and the erasure audit trail reported.

The recordings list no longer reports a count that was not one

The recordings list had an Events column, and the erasure audit entry read "… 24 events, 216367 bytes …". Neither number was an event count: it counts the pieces a connector writes a recording in, so a session containing six typed commands reported 24.

The audit entry now says chunks, which is what it always counted. Audit entries cannot be corrected after the fact, so a reviewer reading one should not have to know that the noun was wrong.

The column is gone from the list. Once labelled truthfully it said nothing that Duration and Size do not — how many pieces a recording was written in is an internal detail, not something to read a session by.

Nothing about recording, replay, search or retention changes.

Upgrading

Manager only. Connectors need no change for this release; 2.0.1 connectors stay compatible.

Two fixes to session recording and monitoring. Upgrade the manager and every connector together — see below.

Session replay no longer hangs on "Loading…"

Opening a recording showed "Loading…" and 0:00 / 0:00 forever, while the typed-input timeline beside it listed only some of the keystrokes it had captured.

A session records more than one stream at the same time — the screen and the keystrokes — and both were being written to the same filenames on the connector, each overwriting the other as the session went on. The player was handed a stream with the wrong data spliced into it and could never start. Each stream is now stored separately, so a recording plays back whole and the timeline lists every keystroke that was captured.

Erasing a recording still erases everything it holds, keystrokes included.

Monitoring a live session no longer drops after a few seconds

Watching an active session connected, showed the screen, then failed within seconds with "The session ended or is no longer available." — while the session was still running. Reconnecting gave the same result.

A viewer that only watches still has to answer the remote desktop service's periodic check, and those answers were being discarded along with the viewer's keyboard and mouse input. The service treated the silent viewer as gone and closed it. Watching now keeps working for as long as the session lasts; a viewer still cannot type or click until they take control.

The server log now records why a view ended, so a dropped viewer is no longer indistinguishable from a session that simply finished.

Upgrading

Recordings made by 2.0.0 cannot be played back — they were stored in the broken layout and were already unreadable. Recordings made from 2.0.1 onward are unaffected.

Upgrade the manager and every connector to 2.0.1. A 2.0.0 connector paired with a 2.0.1 manager will report an error when a recording is opened instead of playing it.

Session recordings now stay on your own infrastructure.

Recordings, keystroke logs and isolated-browser video are written to the connector inside your network, encrypted with a key the connector generates and never sends anywhere. The control plane keeps only an index — which recording, which resource, which user, how large — and cannot decrypt the content. Command search runs on the connector too, so the text never has to leave to be searched.

⚠️ Before you upgrade

1. Upgrade your connectors first. A 1.x connector does not understand the new recording frame and its sessions' recordings are lost.

Use the upgrade command from the console — Connectors → your connector → update command. Do not hand-write a docker run for this: a connector deployment is three containers on a shared captivo-gateway network (connector, captivo-guacd, captivo-kasm) plus several volumes, and the generated command has all of them with the right environment. It pulls :latest, which now points at 2.0.0.

Upgrade every connector first, then the manager and data plane.

2. Back up the connector's volume — and keep it backed up. Nobody else has a copy, including us. If the volume is lost the recordings are gone permanently.

3. Back up /data/recording.key with it. The recordings cannot be read without that file and it cannot be reissued. The connector warns at start-up if its recording directory is not on a mounted volume.

What changes for you

• Search still works. It runs on the connectors that hold the text and merges the answers.
• Playback still seeks. Byte ranges are passed through to the connector, so scrubbing a long video does not download it from the start.
• An offline connector makes an answer incomplete, not empty. The console says which connectors could not be searched rather than reporting "no results" — the two mean opposite things during an investigation.
• Erasure completes when the connector next connects. Asking the console to delete a recording is recorded immediately and marked pending; the content goes when the connector confirms. An offline connector delays it, and the console does not claim otherwise.
• Retention is enforced by the connector, which owns the files, and it reports back what it removed.

Breaking changes

• Connectors must be at 2.0.0. Older ones lose their recordings (logged once per session).
• Four internal endpoints are retired and answer 410: recording ingest-guac, ingest-video, finalize-video and keyevents. Nothing calls them; they refuse rather than store, so a stale data plane cannot quietly keep a central copy.
• SessionRecording gains a nullable purgePendingAt column.

A Data Processing Agreement covering this is published at https://captivo.io/en/dpa-access.

A fresh self-hosted install now asks for a version that exists

Installing from scratch could fail while pulling images. The compose files pinned a fallback version written in by hand — 1.9.0 in one file and 1.10.0 in the other, while the current release was 1.14.0. That was invisible for as long as the old image registry still held every old tag: the fallback was stale, but the stale version was still there to download.

Moving the images to a new registry namespace in v1.14.0 removed that cover. A default install began asking for a version that had never been published there, and stopped.

What changed

• The version this checkout ships is recorded in one place (a VERSION file), and both compose files read the same value.
• setup.sh writes that version into the .env it generates, so a first install pins something that exists rather than relying on the fallback at all.
• A test compares both compose fallbacks against VERSION, so the next time one goes stale the build says so instead of an install failing months later.

Existing installs are unaffected — they already pin a working version in their own .env. Upgrading is the usual git pull, set CAPTIVO_VERSION in .env, and re-run ./setup.sh.

Full changelog

The project has moved to the Captivo organisation

This repository now lives at captivo-io/captivo-access, and the container images now live at *ghcr.io/captivo-io/captivo-access-**. Nothing about the product changed; the code has an organisation behind it instead of a personal account.

If you have a self-hosted install, pull the repository and re-run ./setup.sh when convenient — the compose files point at the new image namespace. The old images at ghcr.io/kurtserdar/* remain public, so an existing install keeps working on the version it has pinned until you choose to move.

Links keep working. The old repository address redirects here, so bookmarks, clones and any documentation pointing at the old URL continue to resolve.

> Installing from scratch on this tag hits a version pin that was already stale before the move — use v1.14.1 instead, which fixes it.

Full changelog

Plan names now match across Captivo products

The plan tiers in Captivo Access are named free, pro and enterprise — the same three names Captivo Portal uses. Previously Access called its middle tier "standard", so an organisation using both products saw two different vocabularies for the same thing.

If your workspace had never been assigned a tier, its allowance line read "Your plan: 0 of 1 connectors used". It now reads "Free plan", which is what it always was.

Nothing about your allowance changed, and self-hosted installations are unaffected: the tier is a label there, and the caps it would describe are not applied.

Full changelog