Privilege Escalation in SAGRES via idPessoa / perfil Parameter Tampering

A vulnerability disclosure. Reported to TecnoTrends in October 2024. Disclosed publicly in May 2026, after fix verification.

Full read+write authorization bypass against an authenticated, network-accessible system handling sensitive academic records.

What is SAGRES?

SAGRES is a closed-source academic-management system: web portal, mobile API, and Android/iOS apps. It is the system of record at multiple Brazilian universities for enrollment, grades, attendance, lecture content, internal messaging, and administrative service requests. The mobile API is a ServiceStack-style REST API.

The vulnerability

SAGRES’s mobile API authenticates users with HTTP Basic credentials. Once authenticated, however, the server did not consistently re-verify that the idPessoa and perfil (profile) values used in the request actually corresponded to the authenticated user. Both parameters appeared in URLs and request bodies on most data-bearing endpoints (/diario/aulas, /diario/faltas, /diario/recados, the grades endpoints, and others). On a substantial subset of those endpoints:

• Replacing idPessoa with another user’s id returned that user’s data.
• Changing perfil from 1 (student) to 2 (teacher), and in some cases other values like 99, granted access to teacher-only response fields and write operations.

In other words, the server trusted the client to declare who it was and what role it held at request time, when the only fact the server should have trusted was the authenticated principal it had already established.

This was reachable from a vanilla student account. No token theft, no MITM, no session manipulation, just two query parameters.

How it was discovered

The first signal came in 2018. As a Computer Engineering student, while exploring why some endpoints returned different data depending on the perfil value, I noticed that changing my perfil from 1 (student) to 2, or in some cases unrelated values like 99, caused the API to expose data that should not have been visible to me, particularly when used together with the embutir (embed) and campos (field projection) parameters that SAGRES exposes.

The observation sat with me for years. I came back to it in 2024 in a fairly mundane context: I was working on heuristics and data-fetch optimizations for UNES, an open-source student-built mobile app for UEFS that consumes the same SAGRES mobile API. While instrumenting how UNES talked to the API, I remembered the strange perfil behavior from 2018 and decided to look at how far it actually went.

Escalation was gradual. First I substituted idPessoa with another student’s id and confirmed the server returned that student’s data. Then I tried with a teacher’s id and watched how the client layer reacted to the responses; they came back clean, with all teacher-scoped fields populated.

At that point I decided to stop hand-rolling requests and adopt a less risky approach for verifying the write surface: rather than reproducing the calls from scratch (with the obvious risk of building a malformed POST and actually mutating something I didn’t intend to), I patched a copy of TecnoTrends’ own official mobile app to accept whichever identity I wanted at login time. The modified build accepted a username in the form username:<id> together with my real password; the client performed a normal authenticated login against the server, and only after authentication had succeeded did it replace its locally-cached identity with the id following the colon. Because the official app already has every endpoint mapped correctly and knows the precise shape of each call, it took care of producing well-formed requests; my modification only changed which identity it then assumed.

That confirmed the flaw: the server served data and accepted writes for whichever identity the client subsequently presented, as long as the client had a valid login from some user. Substituting in a teacher’s id gave full control over lectures, grades, and attendance in every class that teacher was assigned to. The bypass also extended to broadly-scoped collection endpoints (e.g. aproveitamento-alunos) where the combination of embutir and perfil tampering reached even further.

Write capability was verified with explicit consent: a faculty member at UEFS agreed to have their class used as a test environment, allowing me to demonstrate that the bypass let a student-scoped session modify lecture and attendance records under that teacher’s account. I deliberately stopped short of modifying grades even with consent; the line between authorized security testing and academic misconduct is too thin there to risk crossing, and confirmation of the other write vectors was already enough to characterize the impact.

Impact

For the duration this flaw existed in production:

• Confidentiality: any student account could enumerate and read the academic records of every student at the institution, plus internal teacher data.
• Integrity: any student account could alter grades, attendance, and lecture content as a teacher in any class. The institution would have had no easy way to distinguish a forged change from a legitimate one; both would appear in the system as authenticated mutations.
• Multi-tenancy: SAGRES is deployed at multiple Brazilian universities. The vulnerability was in the platform itself, not in any one institution’s configuration, which means the entire SAGRES customer base was potentially exposed for as long as they ran an unpatched version.

This is, for an academic system, the worst class of bug. It is not a leak; it is a complete failure of the system’s authorization model, including the integrity guarantees that diplomas and transcripts depend on.

Disclosure timeline

Vendor response

Five days after the report, the CEO of TecnoTrends replied. The full email, in the original Portuguese:

“Caro João Paulo,

Meu nome é Ricardo Nery e sou diretor executivo da TecnoTrends.

Recebi da área comercial seu e-mail abaixo.

A fim de lhe passar maiores informações, preciso, por favor, saber a sua instituição, desconfio que seja a UEFS, e se o problema referido se refere ao portal de aplicações ou ao aplicativo mobile.

Explico..

Segundo o setor de tecnologia a fragilidade apontada foi realmente encontrada na API do Mobile devido a uma alteração indevida feita voltada ao ensino básico no sentido de permitir pais e responsáveis terem acesso as informações dos seus alunos.

Contudo, tal fragilidade não foi detectada no portal de aplicações.

Como em seu e-mail há uma série de referências expressas ao PORTAL, ficamos sem entender se é uma fragilidade que não detectamos ou a referência feita em seu e-mail diz, em verdade, ao aplicativo mobile já que estamos enfrentando um ataque de engenharia reversa feita através da plataforma Android, algo bem conhecido na área de segurança de aplicativos, que expõe a API.

Até onde investigamos, a API está sendo utilizada por um aplicativo desenvolvido pelos alunos de Computação chamado UNES.

Mas este é um assunto que estamos tratando internamente com o corpo técnico da UEFS.

Fico no aguardo da suas considerações.

Grato!”

Translation:

“Dear João Paulo,

My name is Ricardo Nery and I am the executive director of TecnoTrends.

I received your email below from the commercial team.

In order to share more information with you, I need to know your institution — I suspect it is UEFS — and whether the issue referred to relates to the applications portal or the mobile application.

Let me explain..

According to the technology team, the weakness pointed out was indeed found in the Mobile API, due to an inappropriate change made for basic-education use cases, intended to allow parents and guardians to access their students’ information.

That said, no such weakness was detected in the applications portal.

Since your email contains a number of explicit references to the PORTAL, we are unsure whether this is a weakness we did not detect, or whether the reference in your email is actually to the mobile application, given that we are facing a reverse-engineering attack carried out through the Android platform — something well known in the field of application security — which exposes the API.

As far as we have investigated, the API is being used by an application developed by Computing students called UNES.

But this is a matter we are handling internally with the technical staff at UEFS.

I await your considerations.

Thank you!”

The CEO confirmed the vulnerability existed in the mobile API and attributed the regression to a feature added to support parents/guardians of basic-education students.

The same email also characterized the work as “an attack of reverse engineering carried out through the Android platform” via “an application developed by Computing students called UNES.” It is worth being explicit: UNES is an open-source, student-developed mobile client that consumes the same publicly-deployed SAGRES API any official client uses. The vulnerability was a server-side authorization defect; reverse engineering of the official mobile app revealed it but did not cause it. A flaw in a public-facing API is a flaw whether or not anyone has decompiled the vendor’s APK.

Why this could happen

The root cause, per the vendor itself, was a feature change made for one use case (parents accessing their children’s records in basic education) that loosened the identity-verification logic the rest of the platform depended on. This is a familiar pattern in monolithic systems with weak per-route authorization: a single relaxation, made for a single feature, becomes a cross-cutting bypass everywhere.

Put more simply: the only identity an API server should ever trust is the one it has authenticated. The moment an endpoint accepts a client-declared idPessoa or perfil and uses it to gate authorization, you have a vulnerability, even before anyone exploits it.

Recommendations

For institutions running SAGRES:

• Confirm in writing with TecnoTrends that your installation has the post-2024 patch deployed.
• Audit access logs from the period prior to the fix for admin-scoped reads or writes originating from non-administrative accounts. Even retrospective forensics is valuable here.
• Consider what controls your institution would need to detect grade-record tampering retroactively, if a similar flaw recurs.

For TecnoTrends:

• Establish a security@ contact and a public vulnerability-disclosure policy. Routing security reports through comercial@ introduces avoidable risk and friction for researchers.
• Treat researcher reports as signal, not as “attacks.” The framing in the 2024 reply is a public-relations posture; the technical reality is that a researcher with a student login could have rewritten any student’s transcript at any university running your software, and a subsequent good-faith disclosure is the most favorable outcome you could have hoped for.

For the broader Brazilian education-technology community:

• Closed-source academic platforms processing sensitive records under LGPD should be subject to the same expectations of independent security review, coordinated disclosure, and CVE assignment that the rest of the industry operates under.

Acknowledgments

To the UEFS faculty member who took my report seriously and escalated it within the institution before I had the courage to email the vendor directly. To UEFS administration, for treating this as the serious problem it was. To the professor who consented to having their class used as a test environment to confirm the write vector. To TecnoTrends, for the fix.

A note on timing

I waited 18 months between report and disclosure. That is far longer than the 90-day industry norm. I waited because I wanted reasonable confidence the fix had been deployed and stayed deployed; because I am identifiable (an alumnus of one of the affected institutions, and the maintainer of the UNES app the vendor’s own response named); and because a faculty member I trust, who saw the vendor’s reply at the time, advised me not to re-engage given the framing. I followed that advice.

The fix to the specific bypass is in production and verified. The institution is informed. The vendor has had every reasonable opportunity to coordinate. Disclosure now serves the broader community: other institutions running SAGRES, the security research community in Brazil, and anyone who comes after with similar findings and similar uncertainty about whether publishing is safe.

João Paulo Sena